Buffer overflows are causing continual service pack/security updates across multiple platforms, but mostly in Microsoft's products.

Are there efforts being make to overflow-proof the OS4 kernel, TCP/IP stack and associated libraries? Are there programming guidelines being developed?


Thanks

@gregthecanuck

Overflow exploits do not work on OS 4. Code cannot be executed anywhere; there is a specialized executable memory area where code needs to be placed, so the normal overflow exploits will simply cause a program to crash instead of run malicious code.

_________________
Seriously, if you want to contact me do not bother sending me a PM here. Write me a mail

@Rogue

This is cool

Long live Hyperion and OS4

@Rogue

Nice to read that...

Tuxedo.

_________________
Simone"Tuxedo"Monsignori, Perugia, ITALY.

@Tuxedo

Yes this is good. My understanding is that a very large number of exploits are based on buffer-overrun. With that option unavailable, finding loopholes to be exploited just gets that much harder.

Hans

_________________
Join the Kea Campus - upgrade your skills; support my work; enjoy the Amiga corner.
https://keasigmadelta.com/ - see more of my work

@Rogue

What if 68k code is planted? The problem would be switching from PPC mode to emul mode but in theory, at least in original MMU emul switch approach, it is possible?

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@Hans

Quote:

With that option unavailable, finding loopholes to be exploited just gets that much harder.

The problem is, that option is not unavailable. Buffer overruns can still be used to put attacker-chosen data in places where it doesn't belong; In the (very common) case of a stack buffer overflow, that place contains data that very directly determines the further execution path of the program (i.e. the return address for the current function call).

If a stack buffer can be overflowed, the attacker gets to decide what code is executed next. Simple as that. The traditional way of exploiting this is by simply dumping some exploit code on the stack, and then directing the return address at it. *That* won't work.
However, the attacker can *still* execute any code that is in executable memory. And the attacker can decide, at will, what data to feed that code. The linux core kernel team for that very reason resisted making the stack non-executable for a long time (I think it finally went in a few years later).

While the attacks described in the links above might not work verbatim, due to OS differences, the basic idea applies... An attacker can simply set up a call to a memory-copy function which copies the exploit code into the executable memory area. Or do any of a number of other nasty things.

OS4 derives a small amount of extra security from its use of a single address space (rather paradoxically :). This means that a program's stack is allocated whereever the OS can find sufficient space at the time the program is started. Obviously, where that is depends on what has gone on before, and what else is running. On separate-address-space OSs, the stack tends to be always in the same spot in a program's address space. So you know where the data you send will end up.
Of course, this didn't go unnoticed, and a number of OSs now randomise where they start the stack. They also offer the option to randomise where libraries get loaded (in contrast, exec.library's address is probably fairly predictable).

Summary (quoted from Linus): "In short, anybody who thinks that the non-executable stack gives them any real security is very very much living in a dream world."

@umisef

You're right. I didn't think about using the data to affect the program flow. Nothing beats preventing buffer-overflow from happening in the first place. Personally, I think that we should be getting rid of unsafe functions such as strcpy, etc. from the C standard. At the very least every compiler should warn about using deprecated, unsafe functions. It won't eliminate buffer-overflows, but it will help.

Hans

_________________
Join the Kea Campus - upgrade your skills; support my work; enjoy the Amiga corner.
https://keasigmadelta.com/ - see more of my work

@itix

"Jumping" directly to 68k code would not work.

_________________
Seriously, if you want to contact me do not bother sending me a PM here. Write me a mail

@umisef

Quote:

An attacker can simply set up a call to a memory-copy function which copies the exploit code into the executable memory area.

How would that exactly work? You cannot execute code from the stack, so how would the attacker set up a memory-copy function?

Quote:

Summary (quoted from Linus): "In short, anybody who thinks that the non-executable stack gives them any real security is very very much living in a dream world."

Anybody thinking that executable stacks are a good thing is just too lazy to implement them.

_________________
Seriously, if you want to contact me do not bother sending me a PM here. Write me a mail

@Rogue

Quote:

Rogue wrote: @umisef Quote: An attacker can simply set up a call to a memory-copy function which copies the exploit code into the executable memory area. How would that exactly work? You cannot execute code from the stack, so how would the attacker set up a memory-copy function?

Obviously you can't execute any old function if the stack is not executable. However, if the application you're exploiting performs a memory copy down the track from the buffer-overflow and you happen to be able to overwrite the memory pointers (assuming they're stored in the memory you overwrote), this might be possible. Still, it sounds much harder to do than executing code on the stack directly.

Hans

Last edited by Hans on 27-Jul-2006 at 07:11 PM.

_________________
Join the Kea Campus - upgrade your skills; support my work; enjoy the Amiga corner.
https://keasigmadelta.com/ - see more of my work

@umisef

Quote:

While the attacks described in the links above might not work verbatim, due to OS differences, the basic idea applies... An attacker can simply set up a call to a memory-copy function which copies the exploit code into the executable memory area.

That would of course just crash, on OS4 all mapped executable areas are write protected. You'd have to allocate new executable and writable memory and copy it there, but for that you'd need the return address of the memory allocation function (from register r3) as argument for the memory copy function (in register r5 for IExec->CopyMem[Quick]() for example), and you need to get the addresses of the memory allocation and copy functions first as well, there are no syscalls or something fixed like that which would make it easy to execute the OS functions you need, and for example with C library functions you can't allocate executable memory. But even if there would be syscalls or another easy way to find the functions you need you still have the problem of passing the required arguments to the functions.

On a CPU which uses the stack for function arguments such exploits are of course much easier, but AmigaOS4 is PPC-only

@umisef

Something else that we get for free, that is being announced as a major new security feature in Vista, is that shared libraries are not guaranteed to be in the same place in memory every time (mind you, exec, intuition and the other boot-time libraries are probably in predictable places - Rogue, do something about it! ) - that makes another class of buffer overflow attacks much harder to do.

Quote:

Rogue wrote: @gregthecanuck Overflow exploits do not work on OS 4. Code cannot be executed anywhere; there is a specialized executable memory area where code needs to be placed, so the normal overflow exploits will simply cause a program to crash instead of run malicious code.

This means that OS4 is still vulnerable to "denial of service" (DOS) attacks - am I right?

In other words, someone could crash the TCP/IP stack or any other system libraries with the right code.

This isn't as bad as executing malicious code, but in the long run is there a plan to tighten up the string handling logic to prevent overflows altogether?


Thanks!

@Rogue

Quote:

How would that exactly work? You cannot execute code from the stack, so how would the attacker set up a memory-copy function?

Fortunately (for the attaceker), OS4 comes with lots of memory-copy functions already built-in. Exec.library has one (or several), for example. The code is already there, it just needs to be called.

Another way is to set up the stack so the current function "returns" to the sprintf() routine, and simply "print" your code where you want it (i.e. you put the code on the stack, and get sprintf() to interpret it as a format string and put it where you want it).


Quote:

Anybody thinking that executable stacks are a good thing is just too lazy to implement them.

Considering that Linus actively rejected ready-made patches, and went through a lot of arguments over the issue, that seems a rather silly statement. Call his stance misguided, and that's an arguable opinion. Call him lazy, and you just show that you have no clue what happened.

BTW, out of interest --- DO you believe that non-executable stacks provide any "real security"?

@umisef
A whole lot of words there. Care to show off the actual code to do it? I would think working code would settle the debate rather quickly.

_________________
ExecSG Team Lead

@joerg

Quote:

That would of course just crash, on OS4 all mapped executable areas are write protected.

\

I strongly doubt that *ALL* executable areas are write protected. Rachy would be a bit upset if that were true.... Of course, our (hypothetical) attacker doesn't care whether he crashes a few 68k programs by overwriting the JITed code.

Quote:

You'd have to allocate new executable and writable memory and copy it there, but for that you'd need the return address of the memory allocation function (from register r3) as argument for the memory copy function

*Or* you play a game of numbers. If you, say, allocate 128MB of such memory, what are the odds that the memory at address 128M is part of it? Predtty good, at the moment.
Of course, OS4 actually offers the ability to catch memory access violations; Calling the grim reaper is only the default setup. So nothing stops our intrepid attacker from changing the callback address (which is data, and writable) and thus get multiple attempts.

Quote:

On a CPU which uses the stack for function arguments such exploits are of course much easier, but AmigaOS4 is PPC-only

So you need to (ab)use a function with variable number of arguments (which even the PPC will happily pull from the stack, because there is no other way). Same as the Alpha that 1998 Linux discussion was about.



The important think to keep in mind is that an attacker doesn't try to play by the rules. There is a bit of code somewhere in OS4 which says "find the page this address is on, and make it executable". That bit of code is never meant to be called by a user-level program, but an attacker DOES NOT CARE. It may be deep within what one would call a syscall, but this is OS4, single address space, so it's there to be used.

What makes OS4 users reasonably safe from such attacks is simply the obscurity of the OS. One would need a copy of the OS, and an A1, to develop such an attack; Then one would need to find a victim, and preferably *without* being identifiable as the source. With an average of 6 OS4 machines per UN nation, that is pretty much not going to happen.

@ssolie

Quote:

A whole lot of words there. Care to show off the actual code to do it?

Want to lend me your A1 system for a month?

@umisef

Quote:

umisef wrote: Fortunately (for the attaceker), OS4 comes with lots of memory-copy functions already built-in. Exec.library has one (or several), for example. The code is already there, it just needs to be called.

So how would you cause these to be called? Considering that you can't call anything directly because the stack is not executable.

Quote:

Another way is to set up the stack so the current function "returns" to the sprintf() routine, and simply "print" your code where you want it (i.e. you put the code on the stack, and get sprintf() to interpret it as a format string and put it where you want it).

How would you do that? I thought that the stack grew away from the current stack-frame. If that's true then how would you cause the buffer to overflow into the memory holding the rts address? Added to that, you still have a problem in getting the program to run your copied code. Executable memory is non-writeable, i.e., attempting to write to it will cause the program to crash. Sprintf alone won't copy to a memory location and then mark that area as executable. It sounds to me like a single buffer-overflow probably won't be enough to execute planted code and take over the machine.

Quote:

BTW, out of interest --- DO you believe that non-executable stacks provide any "real security"?

To be fair, what would you call real security? Non-executable stacks eliminate a whole series of possible attacks. At the very least you must admit that it provides increased security. Obviously there are still other tricks that you could use to take control of them machine. Programmers really do need to prevent buffer overruns from happening in the first place. You can't rely on the OS to make up for sloppy programming.

Hans

_________________
Join the Kea Campus - upgrade your skills; support my work; enjoy the Amiga corner.
https://keasigmadelta.com/ - see more of my work

@umisef
Quote:

Quote: A whole lot of words there. Care to show off the actual code to do it? Want to lend me your A1 system for a month?

Hmmm... So it seems we have some quotes from Linus versus the guys with the OS4 source code. Enjoy your argument boys.

_________________
ExecSG Team Lead