In case you've had you're head in the sand recently I'm sure you must
know about the recent WMF bug found in all recent versions of Windows.
The vulnerable function is in SetAbortProc and can be called from a
malicious WMF file as they include executable code by definition.
Windows automatically runs this a WMF file when previewing /
displaying - including from a web page!
WINE is also vulnerable, and still is. However, from a brief look at
my svn repo I think ReactOS is safe. SetAbortProc is in gdi32.dll,
and our version is well out of sync with WINE. I'm not sure if this
is intentional (I don't know which dll's we share directly), but
whoever implements this function must be very careful.
More info at:
http://www.microsoft.com/technet/security/bulletin/ms06-001.mspx
They also have a patch there so anyone running Windows on their
machine is recommended to patch it immediately.
Cheers,
Martin
ion(a)svn.reactos.org wrote:
> - Fix some nasty context switch bugs:
> * We did not update the KPCR's stacklimit/initialstack with the new thread's stacklimit/initialstack.
> * We always assumed V86 frame bias in KeInitializeThreadContext.
> * We did not properly update ESP0 during context switch, to make space for the NPX frame and V86 bias.
> * We did not update fs:18h to point to the new TEB.
> * We did not clear out GS when switching processes, nor update the TSS's cr3.
> * If a new LDT was being updated, we over-wrote EBP (which was supposed to point to the TSS) by the GDT pointer.
> * We used a push/pop esp0 hack which hid the fact we never updated esp0.
> Modified: trunk/reactos/ntoskrnl/ke/i386/ctxswitch.S
> Modified: trunk/reactos/ntoskrnl/ke/i386/thread.c
>
> ------------------------------------------------------------------------
> *Modified: trunk/reactos/ntoskrnl/ke/i386/ctxswitch.S*
> @@ -114,10 +114,6 @@
>
> *--*/
> .globl @KiSwapContextInternal@0
> @KiSwapContextInternal@0:
>
> -#ifdef KDBG
> - //jmp SaveTrapFrameForKDB
> -SaveTrapFrameForKDB_Return:
> -#endif
>
>
> /* Get the PCR. It's faster to use ebx+offset then fs:offset */
> mov ebx, [fs:KPCR_SELF]
> @@ -132,24 +128,36 @@
>
> cli
>
> /* Save the initial stack in EAX */
>
> - mov eax, [edi+KTHREAD_INITIAL_STACK]
>
> + mov eax, [esi+KTHREAD_INITIAL_STACK]
>
Now eax points to the trap frame of the thread we will switch to.
>
>
> + /* Save the stack limit in ecx */
> + mov ecx, [esi+KTHREAD_STACK_LIMIT]
> +
> + /* Make space for the NPX Frame */
> + sub eax, NPX_FRAME_LENGTH
> +
> + /* Set the KPCR stack values */
> + mov [ebx+KPCR_INITIAL_STACK], eax
> + mov [ebx+KPCR_STACK_LIMIT], ecx
> +
>
> #ifdef CONFIG_SMP
> /* Save FPU state if the thread has used it. */
>
> + mov ecx, [edi+KTHREAD_INITIAL_STACK]
> + sub ecx, NPX_FRAME_LENGTH
>
> mov dword ptr [ebx+KPCR_NPX_THREAD], 0
> test byte ptr [edi+KTHREAD_NPX_STATE], NPX_STATE_DIRTY
> jz 3f
> cmp dword ptr _KeI386FxsrPresent, 0
> je 1f
>
> - fxsave [eax-SIZEOF_FX_SAVE_AREA]
>
> + fxsave [ecx]
>
> jmp 2f
> 1:
>
> - fnsave [eax-SIZEOF_FX_SAVE_AREA]
>
> + fnsave [ecx]
>
> 2:
> mov byte ptr [edi+KTHREAD_NPX_STATE], NPX_STATE_VALID
> 3:
> #endif /* CONFIG_SMP */
>
> -
>
> +
>
> /* Save the stack pointer in this processors TSS */
> mov ebp, [ebx+KPCR_TSS]
>
> @@ -158,12 +166,17 @@
>
> jnz NoAdjust
>
The compare operation uses eax which points to the thread we will switch
to. We must use the trap frame from the thread we will switch from.
> /* Bias esp */
>
> - //sub dword ptr ss:[ebp+KTSS_ESP0], KTRAP_FRAME_V86_GS - KTRAP_FRAME_SS
>
> + sub eax, KTRAP_FRAME_V86_GS - KTRAP_FRAME_SS
>
Eax points to the wrong stack. See above.
>
> NoAdjust:
>
> - /* Push ESP0 Value */
> - push ss:[ebp+KTSS_ESP0]
>
>
>
> + /* Set new ESP0 */
> + mov [ebp+KTSS_ESP0], eax
>
Now, we are using the wrong kernel stack on the next exception.
- Hartmut
Hi all,
WaxDragon gets this,
(lib/setupapi/devinst.c:3167) Flags 0x800000 ignored
(./lib/advapi32/service/scm.c:2035) dwBufSize: 0
(subsys/system/services/rpcserver.c:1759) ScmrStartServiceW() called
(ntoskrnl/ke/i386/v86m.c:678) V86GPF unhandled (was cf)
Entered debugger on last-chance exception number 14 (Page Fault)
Memory at 0xf000e739 could not be written: Page not present.
kdb:> bt
Eip:
<ntoskrnl.exe:65a69 (ntoskrnl/ke/i386/v86m.c:383 (KeV86GPF))>
Frames:
<ntoskrnl.exe:65d92 (ntoskrnl/ke/i386/v86m.c:791 (KeV86Exception))>
<ntoskrnl.exe:62a1f (ntoskrnl/ke/i386/exp.c:514 (KiTrapHandler))>
<ntoskrnl.exe:64cb1 (ntoskrnl/ke/i386/trap.s:151 (KiTrapProlog2))>
<00000c33>
kdb:>
I get this,
(lib/ntdll/ldr/utils.c:1190) LdrGetExportByName(): failed to find mxdMessage
(lib/ntdll/ldr/utils.c:2015) Failed to create or open dll section of 'msacm.drv'
(Status c0000135)
(lib/ntdll/ldr/utils.c:2015) Failed to create or open dll section of 'midimap.dr
v' (Status c0000135)
(./subsys/win32k/ntuser/class.c:137) Failed to lookup class atom (ClassName 'SHE
LLDLL_DefView')!
(ntoskrnl/ke/i386/v86m.c:678) V86GPF unhandled (was ec)
Entered debugger on last-chance exception number 14 (Page Fault)
Memory at 0xdeadbeef could not be written: Page not present.
kdb:> bt
Eip:
<ntoskrnl.exe:65aa9 (ntoskrnl/ke/i386/v86m.c:383 (KeV86GPF))>
Frames:
<ntoskrnl.exe:65dd2 (ntoskrnl/ke/i386/v86m.c:791 (KeV86Exception))>
<ntoskrnl.exe:62a5f (ntoskrnl/ke/i386/exp.c:514 (KiTrapHandler))>
<ntoskrnl.exe:64cf1 (ntoskrnl/ke/i386/trap.s:151 (KiTrapProlog2))>
<00003443>
<00000000>
kdb:>
Second reboot it worked after booting linux than reboot warm, third reboot by power on reset,
(ntoskrnl/ke/i386/v86m.c:678) V86GPF unhandled (was ee)
Entered debugger on last-chance exception number 14 (Page Fault)
Memory at 0xdeadbeef could not be written: Page not present.
kdb:> bt
Eip:
<ntoskrnl.exe:65aa9 (ntoskrnl/ke/i386/v86m.c:383 (KeV86GPF))>
Frames:
<ntoskrnl.exe:65dd2 (ntoskrnl/ke/i386/v86m.c:791 (KeV86Exception))>
<ntoskrnl.exe:62a5f (ntoskrnl/ke/i386/exp.c:514 (KiTrapHandler))>
<ntoskrnl.exe:64cf1 (ntoskrnl/ke/i386/trap.s:151 (KiTrapProlog2))>
<00002eee>
<00000000>
kdb:>
I can repeat this over and over with real hardware,
Thanks,
James
Hey everyone, just a quick question.
Does anyone know of an existing application that will accept a bunch
of header files as input and output a list of function prototypes? It
would really help with my code auditing as I'm spending a long time
assembling them by hand and it takes a long while.
Cheers,
Martin
weiden(a)svn.reactos.org wrote:
> disable starting lsass.exe for now
It seems that rpcrt4.dll has a bug that massively leaks threads in an
rpc server. It seems that it leaks one thread per request.
- Thomas
Hello Ged,
> some new toolbar icons
>
> Updated files:
> trunk/reactos/subsys/system/explorer/res/toolbar.bmp
Please use only toolbar bitmaps with 15 pixels height, not 16 !
Regards,
Martin
Hi,
Does somebody see this error?
- Hartmut
gcc -c hal\halx86\mp\processor_mp.c -o
.\up\obj-i386\hal\halx86\mp\processor_mp.o -Ihal\halx86\include
-Intoskrnl\include -D_DISABLE_TIDENTSSMP -D_NTHAL_ -D__USE_W32API -I.
-Iinclude -Iinclude\reactos -Iinclude\libs -Iinclude\drivers
-Iinclude\subsys -Iinclude\ndk -Iw32api\includ\include\crt
-Iw32api\include\ddk -D_M_IX86 -D_X86_ -D__i386__ -D_REACTOS_ -DDBG
-DKDBG -Wall -Wno-strict-aliasing -ftracer
-momit-leaf-fram-mpreferred-stack-boundary=2 -Wpointer-arith -g -pipe
-Werror -D_SEH_NO_NATIVE_NLG
hal\halx86\mp\mpconfig.c: In function `HaliScanForMPConfigTable':
hal\halx86\mp\mpconfig.c:563: internal compiler error: in
cfg_layout_merge_blocks, at cfgrtl.c:2631
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.mingw.org/bugs.shtml> for instructions.
_make: *** [.\up\obj-i386\hal\halx86\mp\mpconfig.o] Error 1
_make: *** Waiting for unfinished jobs....
gcc (GCC) 3.4.2 (mingw-special)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.