Windows Buffer Overflows

From: Brett Moore (brett@softwarecreations.co.nz)
Date: 06/16/02


From: "Brett Moore" <brett@softwarecreations.co.nz>
To: <bugtraq@securityfocus.com>
Date: Sun, 16 Jun 2002 18:54:14 +1200

This following applies to the recent .asp and .htr Buffer Overflows
for IIS and possibly other similar vulnerabilities.

From the eEye Advisory:
ADVISORY: Windows 2000 and NT4 IIS .HTR Remote Buffer Overflow [AD20020612]
"By manipulating the content of these structures we can overwrite an
arbitrary 4 bytes of memory with an attacker supplied address."

This statement is misleading and should read similar to:

"we can overwrite multiple memory addresses with attacker supplied data"

So what is the difference?

From the Eeye Advisory:
"While many may believe that the risk for these types of vulnerabilities is
fairly low due to the fact that addressing is dynamic and brute force
techniques would need to be used in an attack, eEye strongly disagrees. This
premise is false as successful exploitation can be made with one attempt,
across dll versions."

The recent .asp exploits that I have seen all work in a similar way.
They overwrite the exception handler, which is a static memory address
with the address of the payload.
Then when the execption happens code execution jumps to this address.
This address is dynamic, so to reach this address exploits can

1) Hard code the address as in;
 IIS5.0 .asp overrun remote exploit
 Programmed by hsj : 02.04.14
 #define RET 0x0045C560 /* our payload. ugh, direct

2) Brute force the address as in;
 IIS5.0 .asp overrun remote brute force exploit
 by isno(isno@xfocus.org)
#define RET 0x00450000 /* brute force addr */
#define STEP 2000 /* brute force step */

3) Find a static address that has the required code to do a relative jump as
in
 * the address of our payload is at [esp+xx]
 * we find a static location with the instuctions for jmp [esp+xx].

While #3 is obviously the best way, it is not always possible to find the
instructions required.

But because we can write to multiple addresses an exploit can work like
this,
 * locate the static memory address for the exception handler
 * locate another static memory address
 * overwrite the exception handler with the second address
 * overwrite the second address with the required instructions for our
relative jmp
 * cause an exception

The result?

A security vulnerability is always a serious issue. The fact that there are
not
always exploits created and made available to the public, should in no way
suggest
that the risk is lower.

Where did I find this?

It was there inside my computer just waiting for me. And I could almost say
100%
that "I'm not the only one to know this". But it is not something that I
have
seen on any resource for IT Security and as such the general impression has
been
that vulnerabilities of this type are "Low Risk because of the dynamic
address
issue". So either only the true underground know about this or perhaps the
professional IT security industry is somewhat like the NSA,FBI,CIA and
doesn't
like to share information.

Microsoft Resources
-----------------------------------------------------------------------
Title: Heap Overrun in HTR Chunked Encoding Could Enable Web
            Server Compromise (Q321599)
Date: 12 June 2002
Max Risk: Moderate
Bulletin: MS02-028
Mitigating Factors:
====================
 - On default installations of IIS 5.0, exploiting the
   vulnerability to run code would grant the attacker the privileges
   of the IWAM_computername account, which has only the privileges
   commensurate with those of an interactively logged-on
   unprivileged user.
-----------------------------------------------------------------------
Title: Unchecked Buffer in Remote Access Service Phonebook Could
            Lead to Code Execution (Q318138)
Date: 12 June 2002
Impact: Local Privilege Escalation
Max Risk: Critical
Bulletin: MS02-029
Mitigating Factors:
====================
 - The vulnerability could only be exploited by an attacker who had
   the appropriate credentials to log onto an affected system.
 - Best practices suggests that unprivileged users not be allowed to
   interactively log onto business-critical servers. If this
   recommendation has been followed machines such as domain
   controllers, ERP servers, print and file servers, database
   servers, and others would not be at risk from this vulnerability.

So put the together the two vulnerabilities that were released on the
same day, and we have a remote system level exploit for IIS?
Yet the HTR Buffer Overflow only has a Max Risk: Moderate.

Brett



Relevant Pages

  • Windows Buffer Overflows
    ... "While many may believe that the risk for these types of vulnerabilities is ... The recent .asp exploits that I have seen all work in a similar way. ... which is a static memory address ...
    (Vuln-Dev)
  • Re: [Full-disclosure] SMS Banking
    ... You are now saying you can model likelihood of code vulnerabilities based on past discoveries. ... The risk of deploying any given solution takes into account FAR too many real-world elements than any formula can address. ... Please let me know when you've got the contract ready. ... "Thor" has the notion that you cannot quantitatively ...
    (Full-Disclosure)
  • Re: [Full-disclosure] SMS Banking
    ... statement was to predict the risk associated with these. ... " Contract. ... that is I use a model for the risk of these products, and "Thor" can make up ... the vulnerabilities over a time period. ...
    (Full-Disclosure)
  • Re: [Full-disclosure] SMS Banking
    ... but may I also have a contract to be the agent for the ... A selection of software products are tested using both processes, ... software as well as the risk are to be presented as a monthly estimate. ... likelihood of code vulnerabilities based on past discoveries. ...
    (Full-Disclosure)
  • Re: [Full-disclosure] SMS Banking
    ... statement was to predict the risk associated with these. ... " Contract. ... "1 A selection of software products are tested using both processes, ... the vulnerabilities over a time period. ...
    (Full-Disclosure)