Summary: | >=xorg-server-1.4 freezes after first keystroke - stack smashing attack in XkbHandleActions | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Sascha G. <s.geschwandtner> |
Component: | Current packages | Assignee: | Gentoo X packagers <x11> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | asl, eradicator, hardened, jkt, kanelxake, pageexec |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | xorg.conf |
Description
Sascha G.
2007-09-14 23:58:15 UTC
Created attachment 130964 [details]
xorg.conf
I'm seeing this too with a hardened profile and glibc 2.3.6-r5 but with a via card. X will consistently die with various errors after typing a few things into a term and then trying to use tab completion. --- X: stack smashing attack in function XkbHandleActions() --- --- Backtrace: 0: /usr/bin/X(xf86SigHandler+0x91) [0x17c34501] 1: /lib/libc.so.6(__libc_start_main+0xe1) [0x4f77bf41] 2: /usr/bin/X [0x17bcd441] Fatal server error: Caught signal 11. Server aborting --- Backtrace: 0: /usr/bin/X(xf86SigHandler+0x91) [0x1403d501] 1: /lib/libc.so.6(__libc_start_main+0xe1) [0x50bdef41] 2: /usr/bin/X [0x13fd6441] Fatal server error: Caught signal 11. Server aborting --- Backtrace: 0: /usr/bin/X(xf86SigHandler+0x91) [0x11655501] 1: /lib/libc.so.6(__libc_start_main+0xe1) [0x48b81f41] 2: /usr/bin/X [0x115ee441] Fatal server error: Caught signal 11. Server aborting (gdb) bt #0 0xb7f46402 in __kernel_vsyscall () #1 0xb7c25d06 in kill () from /lib/libc.so.6 #2 0xb7c1251e in __stack_smash_handler () from /lib/libc.so.6 #3 0x8018399f in XkbHandleActions (dev=0x80241cc8, kbd=0x80241cc8, xE=0x801f18dc, count=1) at xkbActions.c:1334 #4 0x8018404d in XkbProcessKeyboardEvent (xE=0xb7d14dec, keybd=0x80241cc8, count=1) at xkbPrKeyEv.c:156 #5 0x8017b00f in AccessXFilterPressEvent (xE=0x801f18dc, keybd=0x80241cc8, count=0) at xkbAccessX.c:563 #6 0x80184322 in ProcessKeyboardEvent (xE=0x6, keybd=0xb7d14dec, count=1) at xkbPrKeyEv.c:177 #7 0x800f77ce in mieqProcessInputEvents () at mieq.c:249 #8 0x8008f3da in ProcessInputEvents () at xf86Events.c:241 #9 0x80048d83 in Dispatch () at dispatch.c:421 #10 0x8002c078 in main (argc=9, argv=0xbfd7bf64, envp=0x1) at main.c:452 switching to i686-pc-linux-gnu-3.4.6-vanilla makes the problem go away. (In reply to comment #4) > switching to i686-pc-linux-gnu-3.4.6-vanilla makes the problem go away. For which packages? xorg-server. pie works, just not ssp. Here is more info with pie disabled and just ssp. gdb gives a bit more info. Program received signal SIGABRT, Aborted. [Switching to Thread 1365797696 (LWP 24019)] 0x519d0402 in __kernel_vsyscall () (gdb) bt #0 0x519d0402 in __kernel_vsyscall () #1 0x516afd06 in kill () from /lib/libc.so.6 #2 0x5169c51e in __stack_smash_handler () from /lib/libc.so.6 #3 0x081c89df in XkbHandleActions (dev=0x82b6728, kbd=0x82b6728, xE=0x823361c, count=1) at xkbActions.c:1334 #4 0x081c908d in XkbProcessKeyboardEvent (xE=0x5179edec, keybd=0x82b6728, count=1) at xkbPrKeyEv.c:156 #5 0x081c004f in AccessXFilterPressEvent (xE=0x823361c, keybd=0x82b6728, count=0) at xkbAccessX.c:563 #6 0x081c9362 in ProcessKeyboardEvent (xE=0x6, keybd=0x5179edec, count=1) at xkbPrKeyEv.c:177 #7 0x0813c80e in mieqProcessInputEvents () at mieq.c:249 #8 0x080d6f8a in ProcessInputEvents () at xf86Events.c:241 #9 0x08091793 in Dispatch () at dispatch.c:421 #10 0x08074a88 in main (argc=9, argv=0x5d8e8634, envp=0x1) at main.c:452 (gdb) disas 0x081c89df ..... 0x081c89da <XkbHandleActions+1226>: call 0x807329c <FontMapFind+64> 0x081c89df <XkbHandleActions+1231>: nop Here is more of a disassembly in case somebody can recognise something. 0x081c893f <XkbHandleActions+1071>: call 0x81b94d0 <XkbComputeDerivedState> 0x081c8944 <XkbHandleActions+1076>: mov 0xffffff78(%ebp),%esi 0x081c894a <XkbHandleActions+1082>: movzwl 0x172(%esi),%eax 0x081c8951 <XkbHandleActions+1089>: mov %ax,0x174(%esi) 0x081c8958 <XkbHandleActions+1096>: movzbl 0x12(%edi),%edx 0x081c895c <XkbHandleActions+1100>: movzbw 0x1f(%edi),%ax 0x081c8961 <XkbHandleActions+1105>: and $0x3,%edx 0x081c8964 <XkbHandleActions+1108>: shl $0xd,%edx 0x081c8967 <XkbHandleActions+1111>: or %edx,%eax 0x081c8969 <XkbHandleActions+1113>: mov %ax,0x172(%esi) 0x081c8970 <XkbHandleActions+1120>: mov 0xffffff34(%ebp),%eax 0x081c8976 <XkbHandleActions+1126>: mov %eax,0x4(%esp) 0x081c897a <XkbHandleActions+1130>: lea 0xffffff98(%ebp),%eax 0x081c897d <XkbHandleActions+1133>: mov %eax,(%esp) 0x081c8980 <XkbHandleActions+1136>: call 0x81b92d0 <XkbStateChangedFlags> 0x081c8985 <XkbHandleActions+1141>: mov %eax,%esi 0x081c8987 <XkbHandleActions+1143>: mov 0xffffff70(%ebp),%eax 0x081c898d <XkbHandleActions+1149>: test %eax,%eax 0x081c898f <XkbHandleActions+1151>: je 0x81c899d <XkbHandleActions+1165> 0x081c8991 <XkbHandleActions+1153>: test %esi,%esi 0x081c8993 <XkbHandleActions+1155>: jne 0x81c8af4 <XkbHandleActions+1508> 0x081c8999 <XkbHandleActions+1161>: andl $0xfffffffe,0x64(%edi) 0x081c899d <XkbHandleActions+1165>: mov 0xffffff44(%ebp),%edx 0x081c89a3 <XkbHandleActions+1171>: mov %esi,0x4(%esp) 0x081c89a7 <XkbHandleActions+1175>: movl $0x0,0x8(%esp) 0x081c89af <XkbHandleActions+1183>: mov %edx,(%esp) 0x081c89b2 <XkbHandleActions+1186>: call 0x81c1f90 <XkbIndicatorsToUpdate> 0x081c89b7 <XkbHandleActions+1191>: test %eax,%eax 0x081c89b9 <XkbHandleActions+1193>: mov %eax,%esi 0x081c89bb <XkbHandleActions+1195>: jne 0x81c8a05 <XkbHandleActions+1269> 0x081c89bd <XkbHandleActions+1197>: mov 0xfffff980(%ebx),%eax 0x081c89c3 <XkbHandleActions+1203>: mov 0xffffffd8(%ebp),%edx 0x081c89c6 <XkbHandleActions+1206>: cmp (%eax),%edx 0x081c89c8 <XkbHandleActions+1208>: je 0x81c89fa <XkbHandleActions+1258> 0x081c89ca <XkbHandleActions+1210>: mov 0xffffffd8(%ebp),%eax 0x081c89cd <XkbHandleActions+1213>: mov %eax,0x4(%esp) 0x081c89d1 <XkbHandleActions+1217>: lea 0xffff5b9e(%ebx),%eax 0x081c89d7 <XkbHandleActions+1223>: mov %eax,(%esp) 0x081c89da <XkbHandleActions+1226>: call 0x807329c <FontMapFind+64> 0x081c89df <XkbHandleActions+1231>: nop 0x081c89e0 <XkbHandleActions+1232>: mov %ecx,%edx 0x081c89e2 <XkbHandleActions+1234>: not %edx 0x081c89e4 <XkbHandleActions+1236>: and %dl,0x19(%edi) 0x081c89e7 <XkbHandleActions+1239>: mov 0xffffff78(%ebp),%eax 0x081c89ed <XkbHandleActions+1245>: movl $0x0,0x50(%eax,%esi,4) 0x081c89f5 <XkbHandleActions+1253>: jmp 0x81c8819 <XkbHandleActions+777> 0x081c89fa <XkbHandleActions+1258>: add $0x10c,%esp 0x081c8a00 <XkbHandleActions+1264>: pop %ebx 0x081c8a01 <XkbHandleActions+1265>: pop %esi 0x081c8a02 <XkbHandleActions+1266>: pop %edi 0x081c8a03 <XkbHandleActions+1267>: leave 0x081c8a04 <XkbHandleActions+1268>: ret If I try to disassemble 0x807329c gdb tells me there is no function at that address. I assume that the symbols below are bogus, but disassembling around that range gives: 0x0807325c <FontMapFind+0>: jmp *0x821d2dc 0x08073262 <FontMapFind+6>: push $0x5b8 0x08073267 <FontMapFind+11>: jmp 0x80726dc <_init+24> 0x0807326c <FontMapFind+16>: jmp *0x821d2e0 0x08073272 <FontMapFind+22>: push $0x5c0 0x08073277 <FontMapFind+27>: jmp 0x80726dc <_init+24> 0x0807327c <FontMapFind+32>: jmp *0x821d2e4 0x08073282 <FontMapFind+38>: push $0x5c8 0x08073287 <FontMapFind+43>: jmp 0x80726dc <_init+24> 0x0807328c <FontMapFind+48>: jmp *0x821d2e8 0x08073292 <FontMapFind+54>: push $0x5d0 0x08073297 <FontMapFind+59>: jmp 0x80726dc <_init+24> 0x0807329c <FontMapFind+64>: jmp *0x821d2ec 0x080732a2 <FontMapFind+70>: push $0x5d8 0x080732a7 <FontMapFind+75>: jmp 0x80726dc <_init+24> 0x080732ac <FontMapFind+80>: jmp *0x821d2f0 0x080732b2 <FontMapFind+86>: push $0x5e0 I don't really know what I'm doing here, just posting this in the hope that somebody can spot whether this is an xorg issue or a ssp one. Any ideas, hardened folks? (In reply to comment #9) > Any ideas, hardened folks? after zakalwe helped me debug this, it turned out to be the usual problem tracked in bug #135265. in this particular case, xkb/xkbActions.c:XkbHandleActions() has the following snippet: if (genStateNotify) { if (changed) { xkbStateNotify sn; sn.keycode= key; sn.eventType= xE->u.u.type; sn.requestMajor = sn.requestMinor = 0; sn.changed= changed; XkbSendStateNotify(dev,&sn); } xkbi->flags&= ~_XkbStateNotifyInProgress; } notice the 'sn' variable defined in an inner block (the usual symptom we observed in other similar cases already), the resulting disasm is: 0x81c8b16 <XkbHandleActions+1542>: lea 0xffffffc8(%ebp),%eax 0x81c8b19 <XkbHandleActions+1545>: mov %eax,0x4(%esp) whereas the canary was at $ebp+0xffffffd8, and the xkbStateNotify structure (see /usr/include/X11/extensions/XKBproto.h) is many times bigger than what's left between the ssp computed address for sn and the canary -> stack smash in short order. so either put gcc-4 into -hardened or disable ssp in gcc-3, it's simply not safe and noone's going to fix it now, i think. *** This bug has been marked as a duplicate of bug 135265 *** |