The forthcoming Red Hat Enterprise Linux 3 suite will include a new feature to thwart worms & hackers.
Red Hat Linux Fights Off Worms
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
It’s nice little touches like these that make me like RedHat so much.
I’m not entirely sure if this will actually work, not having ever written a worm myself. But combined with the buffer overflow preventing code, I think RedHat is working hard for a more secure Linux distribution.
-Erwos
Isn’t this similar to the sort of things that recent OpenBSD versions do? Still, sounds like a good idea, and it would be cool if they adopted some other OpenBSD concepts into mainstream Linux (not just the “security enhanced” distros). Then we can justly claim that Linux is seriously designed for security.
if u are going to take the time to write a worm, wouldn’t you want to target an os a lot of people are running like windows? writing a worm for linux is such a waste of time because compared to windows there’s no one running linux anyway
actually, linux is huge on servers, particularly Red Hat Linux. Writing a worm for Linux isn’t as big of a waste of time as you think. Owning a well-trusted server would put you in an excellent position to take over client machines running windows. Putting up a malicious Java applet or Active X control on something like http://www.yahoo.com would probably cause some serious damage.
PIE is just a gimmick, it makes writing buffer overflow exploits a bit harder but not impossible. What is really needed is to make data segments read and write only, that way it is not possible to exploit buffer overflows by writing code into the buffer because the data segment is not executable. Of course buffer overflows could still be used for DOS.
I believe openbsd has this feature on i386, anyone know for sure?
The IA32 can disable writes to segments, but does not have the hardware to disable execution, as best as I can tell. If you can read it, you can run it.
This is one of the best arguments for dumping the x86 series of processors. In general, if a processor supports VM at all, it will offer better support than any Intel design.
OpenBSD has work-arounds to make buffer overflows harder to exploit. They are still possible, and always will be on x86.
I believe openbsd has this feature on i386, anyone know for sure?
Yes. It’s called W^X. Pronounce it like “W xor X”. Writable pages are not executable. On x86-32, there’s a 1gb virtual gap between W and X pages. Google for details.
wouldn’t you lower the ability of how much memory you can address if 1GB is addressed to this “virtual gap” ?
It’s not perfect, but at least its something. Security is built apon layers. So this combined with some other things will make a box a little more secure.
~Nex6
Sounds like security through obscurity. We all know how well that works. I suppose it would only be a matter of time before the memory location is predicted by analyzing the PIE code. Like a few of the above posts said, it will only slow down the motivated.
-W
And here I thought that they were going to do something cool like make use of SELinux.
wouldn’t you lower the ability of how much memory you can address if 1GB is addressed to this “virtual gap” ?
Who said it’s actually mapped anywhere?
Think of it as /dev/null, if you want.
http://www.sikurezza.org/ml/04_03/msg00122.html <– and there is a post of Theo explaining how W^X works. Enjoy.
..data and code segments are completely separated. Most of the time they are even different types of memory (flash RAM vs. SRAM and/or EEPROM vs flash vs SRAM).
Now, before you dismiss hte atmels, remember that there are several OSes written for this line of uControllers, and anyway, I am just mentioning them for the principle idea.
BTW, was this particular weakness of the x86 architecture that made possible to hack the Xbox? If so, I bet MS are now regretting the choice of hardware.
Atmel, of course, AVR.
“”The IA32 can disable writes to segments, but does not have the hardware to disable execution, as best as I can tell. If you can read it, you can run it.””
x86 has hardware implemented read/write/execute permissions for segments. Problem is that the Unix style OS running on x86 effectively disable protection via segmentation by using paging running over a flat memory space. Presumably it’s a speed and complexity trade off, but one that reduces protection available to the OS.
Thanks for the link. That was an interesting read.
“And here I thought that they were going to do something cool like make use of SELinux.”
Quite a few power users would _not_ appreciate SELinux, as it prevents even root from doing some things.
-Erwos
“Quite a few power users would _not_ appreciate SELinux, as it prevents even root from doing some things.”
Well yeah, that’s the point. If some cracker does manage to break into the system, even with root access, they will be limited in the damage that they can do.
Sure it’s an inconvenience to those who didn’t grow up with it, but it’s real security, and not some hack that RedHat just decided to incorporate.
Is it open souce or proprietary?
Its all been done or currently being done on OpenBSD. Another example of Linux “copying” stuff thats been done on BSD for years.
Last time i looked most *BSD were open source. There’s no law out there saying Linux can’t include ideas devoloped in *BSD. Likewise the *BSD hackers take a look at Linux from time to time, and if they see something they like they tend to implement it (new code though unless the linux code can be aquire under dual license like ACPI i think)
Regarding non-executable segments, they are definitely possible with the IA-32 architecture.
The thing is that gcc doesn’t support “far pointers”, i.e. as an OS designer using gcc, you are severely limited in your use of the segmented memory model.
It’s always been like this. Linux borrows security features from BSD and BSD borrows “driver ideas” from Linux. It works both ways. BSD sets the standards, Linux (and Windows – don’t forget that) borrows them as pre-written code and as ideas. Linux architects write a lot of drivers and often sign NDAs to get the specs – the drivers themselves are released under GPL though. So the BSD teams very often examine the Linux drivers and port those over.
It’s a symbiosis in a way. Linux worries about hardware and BSD worries about security and other features.