full-disclosure - stack V heap and MS03-49

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <36402DCC1069D411922D00508B5B2CC21E3F2C06@ex-server1.napier.ac.uk>
From: R.Ferris at napier.ac.uk (Ferris, Robin)
Subject: stack V heap and MS03-49

Question 

MS03-49 is a stack based buffer overflow, as described below in the articles
below. I have also included a description of the blaster exploit, which was
also a stack based over flow. 

"We found some RPC functions which will accept a long string as a parameter,
and will attempt to write it to the debug log file. If we specify a long
string as a parameter to these RPC functions, a stack-based buffer overflow
will happen in the Workstation service on the remote system. Attackers who
successfully leverage this vulnerability will be executing code under the
SYSTEM context of the remote host."  credit Yuji Ukai
http://www.eeye.com/html/Research/Advisories/AD20031111.html
<http://www.eeye.com/html/Research/Advisories/AD20031111.html>  analysis of
MS03-49

"This is a stack buffer overflow vulnerability that exists in an integral
component of any modern Windows operating system, an RPC interface
implementing Distributed Component Object Model services (DCOM). In a result
of implementation error in a function responsible for instantiation of DCOM
objects, remote attackers can obtain remote access to vulnerable systems."
credit  <http://lsd-pl.net/special.html> http://lsd-pl.net/special.html
(blaster exploit)

However the buffer overflow patched by MS03-039 was a heap based.

I remember reading in this list that a stack based overflow would be more
"easily"/"effectively"/"automatically" exploited than a heap based one.
Taking this into account could we summarise that this latest over flow
posses a similar threat as the first RPC DCOM overflow?

Thanks

RF
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031112/d428a20f/attachment.html