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 messa
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 m
> 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,
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 pr
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 vu
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=sb&b=21&m=140672
The problem is in win32k.sys' function GetHardErrorText, which tries to
prepare EXCEPTION data for event log, and seems to b
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/f
