Re: [Full-disclosure] Microsoft Windows XP/2003/Vista memory corruption 0day
Dear Alexander Sotirov,
AS The HardError message is handled by the UserHardError function in
AS WINSRV.DLL. It calls GetHardErrorText to read the message parameters
AS from the address space of the sender. The GetHardErrorText function
AS returns pointers to the caption and text of the message box. If the
AS caption or text parameters start with the \??\ prefix, the function
AS inexplicably frees the buffer and returns a pointer to freed memory.
AS After the message box is closed by the user, the same buffer is
AS freed again in the FreePhi function, resulting in a double free
AS vulnerability.
I may be wrong, but probably this fact doesn't explain the garbage on
the screen in MessageBox. Even use after free() vulnerability doesn't
explain it, because garbage is permanent. There should be some more bug
before second free().
--Thursday, December 21, 2006, 11:11:29 PM, you wrote to [EMAIL PROTECTED]:
AS 3APA3A wrote:
Killer{R} assumes the problem is in strcpy(), because it should not be
used for overlapping buffers, but at least ANSI implementation of strcpy
from Visual C should be safe in this very situation (copying to lower
addresses). May be code is different for Windows XP or vulnerability is
later in code.
AS We discovered this bug some time ago and were preparing an advisory when it
was
AS publicly disclosed. Since the exploit is already public, here's my analysis
of
AS the vulnerability:
AS
http://www.determina.com/security.research/vulnerabilities/csrss-harderror.html
AS It's a double free bug that leads to arbitrary code execution in the CSRSS
process.
AS Alex
--
~/ZARAZA
Ïî÷òåííûå èñêîïàåìûå! Æäó îò âàñ äàëüíåéøèõ ïèñåì. (Òâåí)
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Microsoft Windows XP/2003/Vista memory corruption 0day
3APA3A wrote: AS The HardError message is handled by the UserHardError function in AS WINSRV.DLL. It calls GetHardErrorText to read the message parameters AS from the address space of the sender. The GetHardErrorText function AS returns pointers to the caption and text of the message box. If the AS caption or text parameters start with the \??\ prefix, the function AS inexplicably frees the buffer and returns a pointer to freed memory. AS After the message box is closed by the user, the same buffer is AS freed again in the FreePhi function, resulting in a double free AS vulnerability. I may be wrong, but probably this fact doesn't explain the garbage on the screen in MessageBox. Even use after free() vulnerability doesn't explain it, because garbage is permanent. There should be some more bug before second free(). The buffer that contains the caption and text of the message box is freed before the message box is displayed. The freed memory is allocated again and overwritten with other data. Displaying this other data as a unicode string results in garbage in the message box. Alex ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Microsoft Windows XP/2003/Vista memory corruption 0day
Dear full-disclosure@lists.grok.org.uk,
Since it's already wide spread on the public forums and exploit is
published on multiple sites and there is no way to stop it, I think
it's time to alert lists about this.
On the one of Russian forums:
http://www.kuban.ru/forum_new/forum2/files/19124.html
message was published by NULL about vulnerability in Windows on
processing MessageBox() with MB_SERVICE_NOTIFICATION flag and
message/caption beggining with \??\. Vulnerability seems to be memory
corruption in kernel and causes system crash or hang after few
attempts. It seems to happen because message is logged to event log
and may point to some problem with event logs processing.
Vulnerability details and code may be found here:
http://www.security.nnov.ru/Gnews944.html
There is potential remote exploitation vector if some service uses
user-supplied input for MessageBox() function. Messenger service is
not vulnerable in this way, because it prepends user-supplied input
with additional string.
I contacted Microsoft on this issue on December, 16.
--
http://www.security.nnov.ru
/\_/\
{ , . } |\
+--oQQo-{ ^ }-+ \
| ZARAZA U 3APA3A } You know my name - look up my number (The Beatles)
+-o66o--+ /
|/
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Microsoft Windows XP/2003/Vista memory corruption 0day
Dear lists,
in another Russian forum, Killer{R} made analysis on this issue using
Windows 2000 sources:
http://bugtraq.ru/cgi-bin/forum.mcgi?type=sbb=21m=140672
The problem is in win32k.sys' function GetHardErrorText, which tries to
prepare EXCEPTION data for event log, and seems to be some very old
debugging feature accidently left in production code since Windows 2000.
In Windows 2000 there is a peace of code like:
} else if ((asLocal.Length 4) !_strnicmp(asLocal.Buffer, \\??\\, 4)) {
strcpy( asLocal.Buffer, asLocal.Buffer+4 );
Killer{R} assumes the problem is in strcpy(), because it should not be
used for overlapping buffers, but at least ANSI implementation of strcpy
from Visual C should be safe in this very situation (copying to lower
addresses). May be code is different for Windows XP or vulnerability is
later in code.
--Thursday, December 21, 2006, 2:58:17 PM, you wrote to
full-disclosure@lists.grok.org.uk:
3 Dear full-disclosure@lists.grok.org.uk,
3 Since it's already wide spread on the public forums and exploit is
3 published on multiple sites and there is no way to stop it, I think
3 it's time to alert lists about this.
3 On the one of Russian forums:
3 http://www.kuban.ru/forum_new/forum2/files/19124.html
3 message was published by NULL about vulnerability in Windows on
3 processing MessageBox() with MB_SERVICE_NOTIFICATION flag and
3 message/caption beggining with \??\. Vulnerability seems to be memory
3 corruption in kernel and causes system crash or hang after few
3 attempts. It seems to happen because message is logged to event log
3 and may point to some problem with event logs processing.
3 Vulnerability details and code may be found here:
3 http://www.security.nnov.ru/Gnews944.html
3 There is potential remote exploitation vector if some service uses
3 user-supplied input for MessageBox() function. Messenger service is
3 not vulnerable in this way, because it prepends user-supplied input
3 with additional string.
3 I contacted Microsoft on this issue on December, 16.
--
~/ZARAZA
http://www.security.nnov.ru/
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Microsoft Windows XP/2003/Vista memory corruption 0day
3APA3A wrote:
Killer{R} assumes the problem is in strcpy(), because it should not be
used for overlapping buffers, but at least ANSI implementation of strcpy
from Visual C should be safe in this very situation (copying to lower
addresses). May be code is different for Windows XP or vulnerability is
later in code.
We discovered this bug some time ago and were preparing an advisory when it was
publicly disclosed. Since the exploit is already public, here's my analysis of
the vulnerability:
http://www.determina.com/security.research/vulnerabilities/csrss-harderror.html
It's a double free bug that leads to arbitrary code execution in the CSRSS
process.
Alex
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Microsoft Windows XP/2003/Vista memory corruption 0day
Holy mackerel! Instances of this bug date back to 1999!
http://groups.google.ca/group/microsoft.public.win32.programmer.kernel/browse_thread/thread/c5946bf40f227058/7bd7b5d66a4e5aff
--Pukhraj
On 12/21/06, Alexander Sotirov [EMAIL PROTECTED] wrote:
3APA3A wrote:
Killer{R} assumes the problem is in strcpy(), because it should not be
used for overlapping buffers, but at least ANSI implementation of strcpy
from Visual C should be safe in this very situation (copying to lower
addresses). May be code is different for Windows XP or vulnerability is
later in code.
We discovered this bug some time ago and were preparing an advisory when it
was
publicly disclosed. Since the exploit is already public, here's my analysis of
the vulnerability:
http://www.determina.com/security.research/vulnerabilities/csrss-harderror.html
It's a double free bug that leads to arbitrary code execution in the CSRSS
process.
Alex
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Microsoft Windows XP/2003/Vista memory corruption 0day
Holy mackerel! Instances of this bug date back to 1999! Different bug. That appears to be a trivial exhaustion of CSRSS worker threads through indiscriminate calls to MessageBox+MB_SERVICE_NOTIFICATION, which causes a DoS as no threads are available to serve kernel-mode requests from win32k, stalling GUI processes. I have done my fair share of CSRSS reversing in my better days, and I'm pretty sure that in Windows 2000 and later, a dedicated thread is used for such notifications, not just any thread, any time. Easily verifiable with local net sends and Spy++. It wasn't a bug either, more like a serious design flaw that ignored a very basic Win32 mantra (don't do GUI in a worker thread) - not at all like this double-free ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
