From: Darby Weaver (ccie.weaver@gmail.com)
Date: Mon Jan 26 2009 - 12:35:14 ARST
I'll go read the article again - I think they said their technique has a 1
in 100,000 chance of success. If they had a chance... any true chance...
we'd have a new exploit by now in the wild.
They did find a way to smach the stack.
Anyone ever read "Smashing the Stack for Fun and Profit" by Adelph1 a long
long time ago.... maybe 30 years ago now... It was true then, and it has
not changed now to my knowledge. Anyone ever seen any router, switch,
firewall, pv, server etc. not crash yet? Buffer Overflows are an
intersting reality. The trick is using the buffer overflow to apply
leverage to a system and gaining privilged access.
http://insecure.org/stf/smashstack.html
"*Smashing the Stack for Fun and Profit*." Phrack Magazine 7, 49 (1996):
File *...* IEEE Transactions on Software Engineering 14, 10 (October *1988*):
1462-1477
*Abstract:* On the evening of 2 November 1988, someone infected the Internet
with a worm program. That program exploited flaws in utility programs in
systems based on BSD-derived versions of UNIX. The flaws allowed the program
to break into those machines and copy itself, thus infecting those systems.
This program eventually spread to thousands of machines, and disrupted
normal activities and Internet connectivity for many days. This report gives
a detailed description of the components of the worm...
Buffer overflow - History
In 1988, the Morris worm used a buffer overflow in a Unix program called
fingerd to propagate itself over the Internet.
Later, in 1995, Thomas Lopatic independently rediscovered the buffer
overflow and published his findings on the Bugtraq security mailing list
[1], which caused a wave of new security relevant buffer overflows to be
found. In 1996, Elias Levy (aka Aleph One) published in *Phrack* magazine
the paper "Smashing the Stack for Fun and Profit"[2], a step-by-step
introduction to exploiting stack-based buffer overflow vulnerabilities,
which caused a wave of new buffer overflow exploits to be written *[citation
needed]*.
Then, in 2001, the Code Red worm sent specially crafted packets to machines
executing Microsoft Internet Information Services (IIS) 5.0*[citation
needed]*, triggering a buffer overflow and yielding full administrative
privileges to the worm. (HTTP servers typically must have administrative
privileges to use the standard TCP port 80; IIS5 did not drop its
administrative privileges after using them.) Following in 2003, the
SQLSlammer worm compromised machines running Microsoft SQL Server 2000 by
sending specially crafted packets to those machines and allowing execution
of arbitrary code...
This is what they are trying to do to the IOS...
If they (whoever they are??? - maybe the guys actually engaged in trying to
"test it" - what a concept) could actually have exploited the IOS - Bet your
beans none of us here would be sleeping till we actually resolved and
stopped the "15 Minutes of Fame" by this latest attack...
Therefore: THEY ARE BLOWING SMOKE UP SOMEONE'S.... REAR PARTS... :)
Sorry guys - I call em as I see em...
I love Security and the guys who pay the guys to come tell we need more
security that costs "x" to by and "y" to maintain and very rarely gets the
attention it deserves or costed after someone "did the right thing" and
crossed off a box on some checklist.
1. Manageable Networks - Common Sense Security...
2. Logs - When did it change?
3. Backups - What Changed?
4 Accountability - Yes - we can track every single keystroke you or anyone
else types in a Cisco IOS-based Device.
5. Infinistream - aka Dude!, What's my network devices been doing and who's
been doing for at least 30+ days if you watched everything... think how long
you'd have FORENSIC EVIDENCE if you only watched your network devices - you
know like management traffic.... Hmmm....
6. Control-Plane Awareness - Dude! What's a "control-plane" and where can I
buy the remote controller to fly it anyway?
It's an interesting concept...
The cure: Common Sense Security and Management Tools that are well...
Manageable - RANCID.
An excerpt:
Eureka! Less than a dozen tries and we found the magic numbers. If xterm
where installed suid root this would now be a root shell.
Small Buffer Overflows
~~~~~~~~~~~~~~~~~~~~~~
There will be times when the buffer you are trying to overflow is so
small that either the shellcode wont fit into it, and it will overwrite the
return address with instructions instead of the address of our code, or the
number of NOPs you can pad the front of the string with is so small that the
chances of guessing their address is minuscule. To obtain a shell from
these
programs we will have to go about it another way. This particular approach
only works when you have access to the program's environment variables.
What we will do is place our shellcode in an environment variable, and
then overflow the buffer with the address of this variable in memory. This
method also increases your changes of the exploit working as you can make
the environment variable holding the shell code as large as you want.
The environment variables are stored in the top of the stack when the
program is started, any modification by setenv() are then allocated
elsewhere. The stack at the beginning then looks like this:
<strings><argv pointers>NULL<envp pointers>NULL<argc><argv><envp>
Our new program will take an extra variable, the size of the variable
containing the shellcode and NOPs. Our new exploit now looks like this:
....
On the first try! It has certainly increased our odds. Depending how
much environment data the exploit program has compared with the program
you are trying to exploit the guessed address may be to low or to high.
Experiment both with positive and negative offsets.
Finding Buffer Overflows
~~~~~~~~~~~~~~~~~~~~~~~~
As stated earlier, buffer overflows are the result of stuffing more
information into a buffer than it is meant to hold. Since C does not have
any
built-in bounds checking, overflows often manifest themselves as writing
past
the end of a character array. The standard C library provides a number of
functions for copying or appending strings, that perform no boundary
checking.
They include: strcat(), strcpy(), sprintf(), and vsprintf(). These functions
operate on null-terminated strings, and do not check for overflow of the
receiving string. gets() is a function that reads a line from stdin into
a buffer until either a terminating newline or EOF. It performs no checks
for
buffer overflows. The scanf() family of functions can also be a problem if
you are matching a sequence of non-white-space characters (%s), or matching
a
non-empty sequence of characters from a specified set (%[]), and the array
pointed to by the char pointer, is not large enough to accept the whole
sequence of characters, and you have not defined the optional maximum field
width. If the target of any of these functions is a buffer of static size,
and its other argument was somehow derived from user input there is a good
posibility that you might be able to exploit a buffer overflow.
Another usual programming construct we find is the use of a while loop to
read one character at a time into a buffer from stdin or some file until the
end of line, end of file, or some other delimiter is reached. This type of
construct usually uses one of these functions: getc(), fgetc(), or
getchar().
If there is no explicit checks for overflows in the while loop, such
programs
are easily exploited.
To conclude, grep(1) is your friend. The sources for free operating
systems and their utilities is readily available. This fact becomes quite
interesting once you realize that many comercial operating systems utilities
where derived from the same sources as the free ones. Use the source d00d.
On 1/26/09, Bogdan Sass <bogdan.sass@catc.ro> wrote:
>
> Darby Weaver wrote:
>
>> I read the article... FUD.
>>
>> While I totally agree to patch and keep devices up to date. They have to
>> date succeeded in exploiting a 1700 and a 2600 series router with outdated
>> IOS code.
>>
>> They admit to something like 1 in 100,000 chance of even getting close
>> enough to attempt an exploit... really...
>>
>>
> Unfortunately, the pdf is not quite clear on this - from what I
> understand, they are saying that _current_ exploits have about a 1/100,000
> chance. What they are trying to point out is that it is (at least
> theoretically) possible to increase that chance using their methodology.
> How much is that increase? Not sure (and I don't think they have an
> accurate aproximation either).
>
> Everyone knows any OS can be exploited by using a buffer overflow to pop
>> the
>> stack. It's practically a given.
>>
> From what little I can remember from my programming classes, this is not
> "a given". All input should be checked to make sure that it doesn't overflow
> the existing buffer.
> While i agree that it is very difficult to do this for each and every
> single buffer in an operating system (and this is why buffer overflow
> vulnerabilities are still being found in most OSs), "it happens to everyone"
> doesn't equal "it is a given" :)
>
> It's easier to insert a rogue router into a network and advertise incorrect
>> routing information than it is to pop the stack and gain root on the Cisco
>> IOS...
>>
>>
> There are always easier attacks - and most of the time, those attacks
> involve the human factor (it's always easier to get the password from a
> post-it note than to brute-force it :P ). But this is not the point here :)
>
> --
> Bogdan Sass
> CCAI,CCSP,JNCIA-ER,CCIE #22221 (RS)
> Information Systems Security Professional
> "Curiosity was framed - ignorance killed the cat"
Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Sun Mar 01 2009 - 09:43:40 ARST