|
|
Back to UserFriendly Strip Comments Index
|
Question about buffer overflows in MS vs *nix | by romandas | 2004-12-14 06:14:02 |
|
Well, thoughts, to some extent... | by imperito | 2004-12-14 06:40:40 |
|
I don't think that | by Didactylos | 2004-12-14 06:49:12 |
| I don't really know what I'm talking about ... |
by A_flj_ |
2004-12-14 08:08:25 |
but afaik it's a different approach, asking more from the hardware. This is why *ix-likes got to be so late on PCs, whereas Windoze was there right after DOS.
In *ix-like, code and data areas in mem are handled differently by the kernel. Any process trying to write something into a code area is terminated without warning - there are mechanisms to unmark as code the mem you wish to write into before you try to write into it. Also, each process has security info attached, and is only allowed to do what that user/group is allowed to do. So if your bufer overrun tries to write into code mem, or your code tries a jump into data mem, your process is terminated. This is what really makes *ixes more secure.
Now, if you are able to bypass these protections and compromise a process running as root, using a buffer overflow, that's it, *ix is as compromised as windows is. However, no or few processes on typical *ix boxes run as root when they are accessible from outside - mail, telnet, ssh, web, ftp and the like all run with a user and group which is different from root. This makes *ix boxes less vulnerable to buffer/stack overruns than Windoze, where most server/network-accessible processes run as system - i.e. the rights they have attached are unlimited. However, in most cases this is not such a severe limitation in Windoze itself, nor does it necessarily affect only Windoze, since anybody can configure a *ix box to run most processes as root (X - shudder!), or configure a windoze to run many processes as non-System - however, there are critical services you cannot really run as non-System, unless you really want a non-usable windoze.
The third major difference, which is only indirectly related to buffer overruns is the global architecture. There is no such thing as the kernel on Windoze, although MS calls one of the essential system libs kernel32.dll. On *ix-es the kernel can be considered a lib, but this lib is loaded only once at boot time, all its functions are reentrant and fixed in mem once the kernel was loaded, and typically the calling mechanism is highly efficient (args in registers - Linux, for instance, which isn't really a Unix, has a limitation in the calls due to the small number of registers in Intel-compatibles), whereas the functions in the windoze "kernel" are just ordinary lib calls. This makes a proper separation of what runs where (user or system) difficult on windoze, although the hardware really does support such a nice implementation like *ix-es require it. Now, if you generate a buffer overflow in an arbitrary lib, it shouldn't affect the system. But if the kernel and the user processes are not separated (i.e. libs which pretend to be the system are behaving as if they were loaded into user processes), how can you guarantee that there will be no side effect which could make the system vulnerable?
As for buffer- and stack-checking compilers: again a doomed try of MS to create something as feature-rich as the swiss army knife - and about as usable for specialized tasks (the swiss army knife has a wood saw, try choping trees with it, and you'll get a better understanding of my words). This method to secure systems is already known from ancient times. It's often used in debug versions of compiled code, and production systems intended to be used as firewalls, gateways, or other sorts of security-related machines also use code compiled with such a compiler. But depending on the app it decreases performance with more than 20%, compared to systems which don't run the buffer- and stack-checking code. Therefore this is not really an option on prod-systems - especially workstations. For workstations, IMO working on BSD or Linux (I prefer Linux for workstations) AND NOT BEING LOGGED ON AS ROOT is the best way to ensure protection of mean buffer or stack overflows. |
|
[ Reply ] |
|
Indeed you don't. | by Didactylos | 2004-12-14 08:12:48 |
|
I'll keep an eye out for that, myself. | by swisscheese | 2004-12-14 14:13:34 |
|
|
[Todays Cartoon Discussion]
[News Index]
|
|
