RIAA....what do u think of this crap...

[Gurm]

I'm still failing to understand how saying that you can't exploit Winamp with a bad MP3 is supportive of MS?

I think KvH just has a bug up his ass because yet another year has come and gone and STILL nobody is using Linux.

- Gurm

[R.Carter]

Sure sounds like a hoax.

The only possible thing is that there were (are?) possible buffer overflow issues on some (all?) MP3 players realted to the tags on MP3 files that could possibly be exploited.

However, to do so I imagine that a attack could only be targeted against a particular MP3 player, since the executable tend to be unique.

Nullsoft (the makers of WinAMP) sold out a while back and are owned by AOL, NOT Microsoft.

If people really want to know more about Microsoft, then I'd recommend reading The Microsoft Way and / or Microsoft Secrets.

[Technoid]

BTW: I'm fuzzy on this "overflow" issue, I can't see how a overflow could alow anyone to do anything
Woulden't it just cause a crach??

[Gurm]

Technoid,

It depends on how the player handles an overflow. MOST players would, in fact, probably crash. I could see Media Player doing something bizarre though. But the likelihood of that code being in any way EXECUTED is small (minute, infinitesimal).

- Gurm

[R.Carter]

Originally posted by Technoid
BTW: I'm fuzzy on this "overflow" issue, I can't see how a overflow could alow anyone to do anything
Woulden't it just cause a crach??

The stuff that is used to exploit a buffer overflow is carefully chosen and designed by the attacker. It's not just meaningless data and it will contain a small program.

The overflow causes stuff sent by the attacker to get placed into the applications stack and / or heap space. Once that happens control of the machine is then passed to the attackers executable. The attackers executable can do anything that it wants to using the priviledges of the original application.

After the attackers executable has run it can cause the original program to crash, but the damage may have already been done.

Check out CERT and you'll see overflows exploits tend to be rather common, here are some that were mentioned for 2002. I'm sure that there are others out there.

CA-2002-37 :Buffer Overflow in Microsoft Windows Shell which is related to MP3 and WMA files.
CA-2002-34: Buffer Overflow in Solaris X Window Font Service
CA-2002-29: Buffer Overflow in Kerberos Administration Daemon
CA-2002-26: Buffer Overflow in CDE ToolTalk
CA-2002-25: Integer Overflow In XDR Library
CA-2002-19: Buffer Overflows in Multiple DNS Resolver Libraries
CA-2002-16: Multiple Vulnerabilities in Yahoo! Messenger mentions a buffer overflow.
CA-2002-14: Buffer Overflow in Macromedia JRun
CA-2002-13: Buffer Overflow in Microsoft's MSN Chat ActiveX Control
CA-2002-11: Heap Overflow in Cachefs Daemon (cachefsd)
CA-2002-09: Multiple Vulnerabilities in Microsoft IIS which mentions several buffer and heap overflow exploits
CA-2002-08: Multiple Vulnerabilities in Oracle Servers which mentions several buffer overflow exploits
CA-2002-04: Buffer Overflow in Microsoft Internet Explorer
CA-2002-02: Buffer Overflow in AOL ICQ

[Gurm]

The catch here is that the program has to be so poorly designed that the overflow code will come next in execution order... in other words that they keep their data and their code in just the right order on the stack... it's rare that these exploits actually work as intended, although they are common.

- Gurm

[cjolley]

Originally posted by Gurm
The catch here is that the program has to be so poorly designed that the overflow code will come next in execution order...

Not nessesarily.
The hacker is not going to care what he runs over to get to the jump target.
The hacker doesn't have to hit the next instruction.
Any jump target past the buffer will be fine.
In fact it would be convenient to have the a jump target farther away than the length of the code he wants to execute.
That would lessen the length of data that needs to be sent because less filler would be needed to get to the jump target.
Just fill the buffer with your program, plus enough filler to get your own jump instruction to a jump target in the program and bounce the instruction pointer where you want it.
At least, that's the way I'd do it.
chuck

[Gurm]

Right. But in that case the buffer HAS to be BEFORE the program on the stack, the system has to allow the program to be overwritten in memory (i.e. NOT running protected), and it only works for a SPECIFIC version of the program with a SPECIFIC memory footprint.



- Gurm

[cjolley]

Hey, I din't say it would be EASY!
I'm not sure protected would matter.
The program is allowed to write to it's own space and as far as the OS is conserned it's the program it's self that is doing the writing.
The good news is that it couldn't do anything global like disable interupts and take complete control.
The bad news is that programs like mplayer have rights to do a lot of stuff the logged in use might not.

chuck

[R.Carter]

Originally posted by Gurm
The catch here is that the program has to be so poorly designed that the overflow code will come next in execution order... in other words that they keep their data and their code in just the right order on the stack... it's rare that these exploits actually work as intended, although they are common.

- Gurm

Hmmm... I don't really agree. I suppose this might make it a bit more clear.

A buffer overflow attack occurs when a hacker overflows an input buffer on the execution stack of an appliction by giving more data than the application was designed to accept. Buffer overflow attacks exploit the lack of bounds checking on the size of input data that is being stored in a data buffer. The weakness is a common programming mistake. The programmer assumes that the application will always be given properly formatted input and they fail to do sanity checking.

The overflow attack data is usually composed of three elements:

1. Arbitrary strings to achieve the buffer overflow: An attacker can, through trial and error, determines the right amount of data necessary to generate an overflow condition.
2. Malicious/Exploiting Code: The attacker provides an input string that is actually executable, binary code that will be used to run additional commands on the system.
3. A change of the return address: The buffer overflow changes the return address to point to the malicious/exploiting code. When the function returns, the exploiting code is executed.

For example,

void httpdProcessRequest(server)
     httpd   *server;
{
     char    dirName[HTTP_MAX_URL],

....

     server->response.responseLength = 0;
     strcpy(dirName, httpdRequestPath(server)); // <<<< here.

In the above code, dirName isn't checked. So if someone passes in a request path that is much larger than the size of dirName it will overwrite the stack.

To fix this, you need to change the strcpy to strncpy(dirName, httpdRequestPath(server), HTTP_MAX_URL);

If you want a more technical information, there is a paper here.

[Gurm]

Yes yes. The problem lies in #3.

Let's say you have the following situation:

00000: Stack
01000: | | Jump Points, Vectors, System Crud...
02000: | | Unchecked String Buffer
03000: | | | |
04000: | | \ /
05000: | | Some other variables
06000: \ /
07000:Program
08000: | |
09000: | |
0A000: | |
0B000: | |
0C000: | |
0D000: | |
0E000: | |
0F000: \ /

Now, you blow out the string buffer. You have to know EXACTLY where the code in the program is executing - no easy task, given that this unchecked buffer condition could happen ANYWHERE in the program. I imagine Winamp accesses the ID3 tag buffer a half dozen times in the course of the code.

---------------

Alternately, you might have the following situation:

00000: Stack
01000: | |
02000: | | Unchecked String Buffer
03000: | | | |
04000: | | \ /
05000: | | Some other variables
06000: \ / Jump points, Vectors, system crud...
07000:Program
08000: | |
09000: | |
0A000: | |
0B000: | |
0C000: | |
0D000: | |
0E000: | |
0F000: \ /

In THIS case, you merely have to know how big the stack is (not so hard). Then you overwrite the return vector, such that when the current loop/routine/etc. is done executing, YOUR code gets executed next.

----------------------------------------

- Gurm

[isochar]

http://www.cdfreaks.com/news2.php3?ID=5513

[TnT]

Originally posted by The PIT
I like Microsoft becuase they keep me employed sorting there software out.

ROTFLMAO

I never thought of that! Without MS and Apple around I might be unemployed too!

[KvHagedorn]

What was that story about a sysadmin who switched to MS because his novell network had worked so flawlessly for years that he forgot how to troubleshoot it?

[The PIT]

Originally posted by KvHagedorn
What was that story about a sysadmin who switched to MS because his novell network had worked so flawlessly for years that he forgot how to troubleshoot it?

I think thats a case of extreme if it ain't broke don't fix it syndrome until he got bored. Novell's broken a few things over the years so I don't hink he did much upgrading.