Slashdot Mirror
Exec Shield for the Linux Kernel
DarkOx writes "There is a new patch from Ingo Molnar which can prevent overflow attacks. The scoop from KernelTrap is as follows: Ingo Molnar has announced a new kernel-based security feature for Linux/x86 called 'Exec Shield'. He describes the patch, which is against the 2.4.20-rc1 kernel, as: 'The exec-shield feature provides protection against stack, buffer or function pointer overflows, and against other types of exploits that rely on overwriting data structures and/or putting code into those structures. The patch also makes it harder to pass in and execute the so-called 'shell-code' of exploits. The patch works transparently, ie. no application recompilation is necessary.'"
Now we can get java slowness in all applications in one easy step! In addition, we can now write sloppy code and just tell people to install this patch first! Finally, open source programming has gotten easy.
Sounds like much of the same security that's been available from grsecurity.net for quite a while now.
prevent people from logging into X as root and screwing up their system.
A cure for stupidity is a many-splendored thing - Publius Julius Caesar on the day before the ides of March ## B.C.
Two stories today with reasons to switch to linux. First IE dies with simple HTML (But really is it any surprise that this is possible) and now a sweet knewe patch for linux. Could it be any better?
"It is not how things are in the world that is mystical, but that it exists." -Ludwig Wittgenstein
http://people.redhat.com/mingo/exec-shield/ANNOUNC E-exec-shield
./cat-lowaddr /proc/self/maps /lib/ld-2.3.2.so /lib/ld-2.3.2.so /lib/libc-2.3.2.so
_____________________________________________
[Announcement] "Exec Shield", new Linux security feature
We are pleased to announce the first publically available source code
release of a new kernel-based security feature called the "Exec Shield",
for Linux/x86. The kernel patch (against 2.4.21-rc1, released under the
GPL/OSL) can be downloaded from:
http://redhat.com/~mingo/exec-shield/
The exec-shield feature provides protection against stack, buffer or
function pointer overflows, and against other types of exploits that rely
on overwriting data structures and/or putting code into those structures.
The patch also makes it harder to pass in and execute the so-called
'shell-code' of exploits. The patch works transparently, ie. no
application recompilation is necessary.
Background:
-----------
It is commonly known that x86 pagetables do not support the so-called
executable bit in the pagetable entries - PROT_EXEC and PROT_READ are
merged into a single 'read or execute' flag. This means that even if an
application marks a certain memory area non-executable (by not providing
the PROT_EXEC flag upon mapping it) under x86, that area is still
executable, if the area is PROT_READ.
Furthermore, the x86 ELF ABI marks the process stack executable, which
requires that the stack is marked executable even on CPUs that support an
executable bit in the pagetables.
This problem has been addressed in the past by various kernel patches,
such as Solar Designer's excellent "non-exec stack patch". These patches
mostly operate by using the x86 segmentation feature to set the code
segment 'limit' value to a certain fixed value that points right below the
stack frame. The exec-shield tries to cover as much virtual memory via the
code segment limit as possible - not just the stack.
Implementation:
---------------
The exec-shield feature works via the kernel transparently tracking
executable mappings an application specifies, and maintains a 'maximum
executable address' value. This is called the 'exec-limit'. The scheduler
uses the exec-limit to update the code segment descriptor upon each
context-switch. Since each process (or thread) in the system can have a
different exec-limit, the scheduler sets the user code segment dynamically
so that always the correct code-segment limit is used.
the kernel caches the user segment descriptor value, so the overhead in
the context-switch path is a very cheap, unconditional 6-byte write to the
GDT, costing 2-3 cycles at most.
Furthermore, the kernel also remaps all PROT_EXEC mappings to the
so-called ASCII-armor area, which on x86 is the addresses 0-16MB. These
addresses are special because they cannot be jumped to via ASCII-based
overflows. E.g. if a buggy application can be overflown via a long URL:
http://somehost/buggy.app?realyloooooooooooooooooo oong.123489719875
then only ASCII (ie. value 1-255) characters can be used by attackers. If
all executable addresses are in the ASCII-armor, then no attack URL can be
used to jump into the executable code - ie. the attack cannot be
successful. (because no URL string can contain the \0 character.) E.g. the
recent sendmail remote root attack was an ASCII-based overflow as well.
With the exec-shield activated, and the 'cat' binary relinked into the the
ASCII-armor, the following layout is created:
$
00101000-00116000 r-xp 00000000 03:01 319365
00116000-00117000 rw-p 00014000 03:01 319365
00117000-0024a000 r-xp 00000000 03:01 319439
0024a000-00
lf(1): it's like ls(1) but sorts filenames by extension, tersely
This is quite nice -- more protection against kernel stack smashers.
I really hope this makes the next RedHat dist.
Its funny, everyone makes fun of RedHat and security, but they really do try, and with some good disabling of services that don't need to be run, RedHat is pretty secure.
Excellent work.
Watch SCO claim this came from them...
FP!!!!! (well, hopefully so... but my browser is taking forever to do anything with this new patch...)
Well, yes and no. Think about the analogy of this to driving. Cars today have a number of safety features, including seat belts, air-bags, anti-lock breaks, etc. Do we drive less safely because of them? More importantly, should we not include these devices in cars to increase driving safety?
I believe it was Chris Rock joking about this in one of his sketches. He claimed that airbags are NOT going to make someone drive safely. He said something like "What you need is a giant spike coming out of the steering wheel. That'll make someone drive safe!".
make world, not war
How is this different from the buffer overflow protection offered by LIDS? Just asking...
Intelligent Life on Earth
While of course all of our software should be correct, using the Operating System to make software more robust is almost always a good thing.
Assuming their claims of extremely low over-head are true, why would we not want this?
In fact, a lot of security issues could be stopped before they ever happen if we look more closely at the Operating System instead of all the software! Think how much easier it would be to work on isolating software and protecting the system from itself than trying to make every single app ever written secure. Yes, focusing attention to the Operating System for vulerabilites is a good step--even though we can't ignore our applications.
You do realise this kind of advancement would not be possible with out assistance from highly successful companies like SC...
Hrm...
"Shit, spaceballs, there goes the planet" --apes
"You should always go to other people's funerals; otherwise, they won't come to yours." -- Yogi Berra
Thank you SCO!
It's great to see that you're at the cutting edge of Linux development!
Linux could play games other than Q3/UT, have the ability to easily install programs. Don't get me wrong, I'd switch to Linux if I could do the same things in it that I can in Windows.
But I can't.
To change the starting virtual address of a binary, just change the linker script (or use a command-line option to the linker). Why did they have to patch binutils?
They could also link with "--emit-relocs" to leave the relocations in the binary. Then it could run in low memory or at the usual address (0x8048000).
I'm trying to understand this fully, but I don't have all the background to do so.
:-)
From the announcement:
It is commonly known that x86 pagetables do not support the so-called executable bit in the pagetable entries - PROT_EXEC and PROT_READ are merged into a single 'read or execute' flag. This means that even if an application marks a certain memory area non-executable (by not providing the PROT_EXEC flag upon mapping it) under x86, that area is still executable, if the area is PROT_READ.
Is this limitation in the x86 processor MMU, or in the Linux kernel?
Is anyone working to fix this limitation? (E.g. AMD fixing it in 64-bit mode on the Opteron, or someone reworking the Linux kernel)
Furthermore, the x86 ELF ABI marks the process stack executable, which requires that the stack is marked executable even on CPUs that support an executable bit in the pagetables.
Does this statement imply that some x86 processors do the right thing with PROT_EXEC?
If Linus is willing to create a new ELF standard, could this problem be fixed? Would it be worth the pain of a new incompatible ELF standard? Are there any other problems that can only be fixed with a new version of ELF, so we can fix them together?
It would be sort of cool to get a new ELF standard, so that Linus can call the new kernel "3.0"!
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
Another saturday night spent on
Someone on lkml asked:
Slightly off-topic, but does anybody know whether IA64 or x86-64 allow you to make the stack non-executable in the same way you can on SPARC?
and hpa replied to this:
x86-64 definitely does, and it's the default on Linux/x86-64.
Up to now, x86 chips have not been able to separate Read from Execute privileges for memory segments, which makes it hard to make stacks non-executable. This is excellent news for anyone looking forward to AMD's x86-64 chips...it keeps looking like they've done the Right Things.
to what this whitepaper is talking about?
The page says they are mapping all the code in the lower 16 MB of the address space. And they keep the first MB unmapped for NULL pointer protection.
;) They are emulating Windoze, you can't be serious about those 15 MB! That'll hardly contain GDI.DLL!
That leaves us with only 15 MB of space for code!
Are they really trying to say that they have not hit that limit yet? No program on earth has more than 15 MB code?! I can hardly believe that.
I was going to cite Emacs on this one, but Emacs is an interpreter, so the actual interpreter code might be small enough. Mhh. What about Mozilla?
Heck, what about WINE?!
I've written a few pieces of code which take advantage of the executability of the stack and the heap. For example if you want to write a just-in-time compiler for some language, an easy way to do it is allocate an area on the heap, let the JIT compiler write the appropriate x86 machine code into that area, and then typecast the area pointer to a function pointer and execute it.
With this patch, that won't work...
Sunlit World Scheme. Weird and different.
(As I'm sure you can tell) I don't claim to know much about any of this at all, but I did read the kerneltrap post, for what it was worth, and as a non-x86 user, I have a few questions. Ingo's patch is only for x86; is equivalent protection for other architectures possible, or even necessary? To what extent are buffer-overflow exploits architecture specific?
Sorry if I'm missing something simple here.
wow... you need to get a clue... statistically speaking, those safety devices HAVE increased reckless driving DRAMATICALLY. People assume since they are wearing a seatbelt they can crash at higher speeds and be just as safe.
anyone know if they will be affected by this change?
Quoting from the README: Non-executable user stack area.
Most buffer overflow exploits are based on overwriting a function's return address on the stack to point to some arbitrary code, which is also put onto the stack. If the stack area is non-executable, buffer overflow vulnerabilities become harder to exploit.
Another way to exploit a buffer overflow is to point the return address to a function in libc, usually system(). This patch also changes the default address that shared libraries are mmap()'ed at to make it always contain a zero byte. This makes it impossible to specify any more data (parameters to the function, or more copies of the return address when filling with a pattern), -- in many exploits that have to do with ASCIIZ strings.
However, note that this patch is by no means a complete solution, it just adds an extra layer of security. Many buffer overflow vulnerabilities will remain exploitable a more complicated way, and some will even remain unaffected by the patch. The reason for using such a patch is to protect against some of the buffer overflow vulnerabilities that are yet unknown.
Also, most of those features do not actually solve the problem they address: An airbag won't stop you from wrapping the car around a tree, it just lets you walk away afterwards; the car is still totaled. It's the same with this patch.
The patch works transparently, ie. no application recompilation is necessary."
:)
Why would you ever need to recompile an application to take advantage of a kernel patch? I could see the need to recompile libraries or statically compiled applications, but it seems logical to me that a kernel patch should only require you to patch the programs that use the kernel source code: the kernel (maybe some modules too, but I don't think that's the case here).
Not trolling, just wondering aloud, so feel free to correct me if I'm wrong.
My blog
Did I miss something? Were you unable to see the site? It still comes up fine for me.
IIRC, `Executive Shield' was (is?) the name of a product that Norton used to hawk for Win9x. Anyone back me up here?
When encryption is outlawed, bayl bhgynjf jvyy unir cevinpl.
Sure, this will nullify most remotely exploitable vulnerabilities, but what about local ones that are vulnerable in the manners I just described?
I stopped wearing a seatbelt as soon as I got a car with an airbag. And now that I have a car with EIGHT (count 'em) airbags and ABS brakes I drive like Mario Andretti. Only without all the cologne.
Actually, I was trying to be Insightful, not Funny.
Proof? I've never heard of such a thing...
My name is Igno Molnar
You kill -9 my ppid
prepare to die!
It's against the 2.4.21-rc1 kernel, not 2.4.20-rc1.
Darn you Nader! Darn you to heck!
BTW mandatory seatbelt laws did increase the percentage of accidents caused by careless driving.
I found my inner child, then I got caught abusing it...
While it is true that in general even HUGE changes to the kernel rarely need an application recompile, and are transparent, sometimes this is not the case.
Consider the following:
Actually, even this patch is not entirely transparent. In order to best benefit from the ASCII-armor area, you will notice that in the readme text file they actually gave a patch to binutils to make executables try and use a lower address for their program text. Executables (unlike shared libraries) aren't relocatable and thus need to be re-linked in order to use a different (lower) address...
... assuming that the stack memory is marked as executable in the binary - which will have the net effect of turning off the Exec-shield.
In other words, ELF format has flags to indicate if the stack should be readable and/or executable. If your doing that sort of thing, make sure that the flag is set, and you'll have no problems [0].
It your doing those sort of tricks, your probably being very careful with what goes where, and buffer lengths and such. The problems come in when people don't realise that there could be a problem, and don't audit the buffer handling code properly.
So, don't worry, just use the ELF flags.
[0] Well, you could set the feature to ignore what the binary says, and implement the security anyway. But that's not a good idea, and very much not default.
Well i guess SCO can use one of those after being "DOSed"..... :) /*Why is the a penguin on my desktop?!*/
The lunatic is in my head
is this a patch i should have installed on my various linux servers? I understand any new code should be tested on a development server before being moved to production, but assuming this patch doesnt cause any problems, is it something thats worth the time and effort to help reduce buffer overflows ?
Lawyers, MBA's, RIAA? A jedi fears not these things!
n/t
All that we see or seem is but a dream within a dream.
We're talking about Linux here, not Windows. Windows doesn't have security, windows has binary compatibility. Linux makes a point of breaking binary compatibility every few months. Notice that Redhat went from 7.3 to 8.0 to 9.0? All of those broke binary compatibility. Linux has a terrible history in regards to kernel changes affecting userland binaries.
mailto:sales@destroyads.com
It should also be pointed out that while most buffer overflow exploits do indeed simultaneously overwrite the return address and inject the shellcode onto the stack, a certain class of buffer overflow exploits called return-into-libc attacks do not require executable stacks and are not too difficult to construct. These attacks overwrite the return address with the starting address for one of the libc exec*() functions. At the same time, the parameters for executing /bin/sh are pushed onto the stack. The execution of the corresponding return instruction then causes the exec*() function to execute /bin/sh. See this paper for a more detailed analysis of some buffer overflow solutions.
I think that it's interesting that in the past few weeks, several solutions for buffer overflows have been announced (e.g., the OpenBSD announcements). Each of these solutions are good solutions, but they heavily borrow from earlier solutions. Unfortunately, the previous work has often not been properly acknowledged. Since the masses are generally not aware of the current state of the art, these supposedly new solutions are given more credit than due. Still, I suppose it's a good thing if general awareness of the buffer overflow problem is raised, even if the pioneers of the technology do not receive their due credit.
Tim Tsai
actually, go ahead, if you are chump enough to do that, you dont deserve those mod points anyhow
This doesn't even deserv a reply but I will give you one anyway (anonymously of course). How much did the rumor in you jain mail buddies email promise you billy would pay ya? I have some unfortunate news. Its not true...Get a life!!!
gdb needs an executable stack or you don't get full breakpoint and watchpoint functionality. Flagging binaries isn't likely to fix this properly, unless you can have the gdb flag override the subordinate executable's.
They deserve it -100 FLAIMBAIT
There's no Freedom like UFP-dom
Windows has allowed people to login as Administrator for more than a decade with no ill effects. It's "More Secure than a Bank Vault."(tm)</sarcasm>
You can't judge a book by the way it wears its hair.
Maybe I'm missing something really simple, but here's my understanding:
1) x86 stack grows from high addresses to lower ones, allowing for a string allocated on the stack to overflow such that it overwrites the return address.
2) x86 is little-endian which means that the return address (in this case, on the stack) starts with the low byte and stops with the high byte.
3) In C programs, strings are null-terminated.
The ASCII shield relies on ASCII not being able to represent certain addresses, namely 0x00000000 to 0x0100ffff.
Well, here's what I don't get. Assuming all three above, there are five possibilities we can generate for overwriting an address:
1) All four address bytes are overwritten by ASCII characters generating an address greater than 0x01010101.
2) The first three bytes are overwritten by ASCII characters, and the last one is overwritten by the null terminator. This results in an address between 0x00010101 and 0x00ffffff. This certainly looks like an address within the 16M "armor"
3-5) For (3), we only overwrite three of the address bytes, the first two being ASCII, and the last being NUL, resulting in an address something like 0x??00AAAA, where AAAA is greater than 0x0101. This would require that the attacker know what the upper byte of the address is, which is possible. (4) and (5) represent similar situations.
As far as I can see, this 16M protected region doesn't exist. WHAT AM I MISSING?
Thank you.
Even though this Exec Shield Owerflow Protection is great; where is the Executive owerflow protection that will protect me from my boss when he wants to execute me?
Melius mori in libertate quam vivere in servitute.
I've been screwing around with mprotect() and friends lately to write a exploit delivery system that can't be read by memory inspection tools on the target machine. While checking to see if similar techniques are possible on Windows, I found that the default addresses for PE/i386 executables' stack and text sections are all below 0x00ffffff. .text begins at 0x00400000, for example, and the stack is located below it.
:) I was wondering for the longest time why they chose those mappings by default until I saw this article today.
So it looks like Microsoft beat Ingo to it
-- thalakan
I am so drunk right now, but it makes me hate microsoft more, Windows should be free like beer and bitches. Because all you people are cool
To change the starting virtual address of a binary, just change the linker script (or use a command-line option to the linker). Why did they have to patch binutils?
Perhaps the patch to GNU Binutils only modified the default linker scripts used by GNU ld on one or more common platforms.
Will I retire or break 10K?
but well... ingo isn't such a "douchbag"
the latest OpenBSD release has the same feature... called W^X (W xor X)
Economically speaking, it's true. Though I will admit I have no hard numbers to give you.
People have a marginal value for driving dangerously, which is balanced by the marginal cost of that action. Where the two meet (marginal cost -vs- marginal value curve), is how people behave (or drive in this case).
In comes a safety feature. That safety feature reduces the marginal cost of driving dangerously. Thus, the driver is able to "afford" more dangerous driving. ie the equilibrium point where marginal value and marginal cost meets has shifted higher towards dangerous driving.
Thus, in economics theory, the driver will drive more dangerously with additional safety features.
The opposite effect, in the original poster's example, of having a spike come out greatly increases the marginal cost. Thus, the "affordable" point shifts far down towards much safer driving.
Of course... this is fundamental microeconomics, and I'm no expert in economics.
(\(\
(^.^)
(")")
*beware the cute-bunny virus
Don't you think after years of bug fixes from Microsoft that they would have "innovated" this sort of thing first with all the money they make...?
If and when different pages are used for code and data, since both already use different segment descriptors, the code and data have their own completely isolated address spaces, so trying to invoke a buffer overflow that would cause a "return" to some point in the user-supplied data would actually simply cause a return to the corresponding point in the code page, which is, of course, not actually modified by the application. At best, a buffer overflow could cause a branch to a particular section of the existing program, but would not permit the execution of arbitrary code since in the ideal case, even the kernel code resides in an address space that is invisible to any running application. The most probable upshot of trying to "return" in this fashion would be a segmentation fault, which should result in no more than the application simply terminating with a core dump.
File under 'M' for 'Manic ranting'
as much as I'd like to believe that Linux is better than it really is, the truth is preferable to self-delusion. I can see that you, however, are a true Open Sores zealot; as such, it is only to be expected that you cannot spell, and that any spell-checking software you might use is broken. You probably don't bathe, and you don't have any friends of the opposite sex.
How do I know this, you ask?
just like the humble blood clot... turboporsche@telus.net
Excatly true, and in some parts of Australia, there are laws prohibiting the use of full role cages and racing harnesses because they make a vehicle safer at high speed, thus enticing the driver to drive at a higher speed.
it is only after a long journey that you know the strength of the horse.
If you use linux with BIG_MEM (3GB/1GB split) enabled in the kernel, your .text segment is allocated starting at 0x00010000. I forget why but there was some simplicity to using the 1GB/1GB split otherwise on linux (.text starting at 0x80000000, kernel mem at 0xc0000000). Windows uses a default 2GB/2GB split, so it makes sense it would start at 0x0. I don't think they were thinking about ASCII armor when they made that decision in the NT 3.x days.
Fuck Beta. Fuck Dice
You know.. you may be right.. consider this little program. It is a series of characters in an array.. the characters are 0x01,0x01,0x01,0x00 (as was your case (2)). When you print this out as an int, you get 65793. This is certainly less than 16 million.
#include <stdio.h>
#include <string.h>
int main(void)
{
char arr[sizeof(int)] = { 0x01, 0x01, 0x01, 0x00 };
printf("%d\n", *((int *)arr));
return 0;
}
So I don't get what Ingo means when he says that this region is somehow ASCII-shielded... because you are right.. on the x86 the high order byte is last, not first (as was the assumption in Ingo Molnar's little readme).
What GIVES??! Anyone? What am *I* missing?
You know an airbag is only designed to work when you wear your seatbelt?
<Amanda`> I just went out to the parking lot in my bathrobe to exchange warez CDs.
*ducks*
All's true that is mistrusted
Sadly, this is true. 'Tis a pity.
note to moderators: linux bashing is only wrong when it's lies.
...stupid languages like C don't do array bounds checking. Compile all your code with Purify on, or use a language with checking, and you'll be a whole lot safer.
Who cares if it takes a few cycles more - for almost all applications is just isn't going to matter, and you can sit back and -relax- rather than having to deal with the next patch to fix a newly discovered hole.
*Linux is dying
Yet another crippling bombshell hit the beleaguered *Linux community when last month IDC confirmed that *Linux accounts for less than a fraction of 1 percent of all servers. Coming on the heels of the latest Netcraft survey which plainly states that *Linux has lost more market share, this news serves to reinforce what we've known all along. *Linux is collapsing in complete disarray, as further exemplified by falling dead last in the recent Kreskin test.
You don't need to be a Kreskin to predict *Linux's future. The hand writing is on the wall: *Linux faces a bleak future. In fact there won't be any future at all for *Linux because *Linux is dying. Things are looking very bad for *Linux. As many of us are already aware, *Linux continues to lose market share. Red ink flows like a river of blood. Debianis the most endangered of them all.
Let's keep to the facts and look at the numbers.
Redhat leader Theo states that there are 7000 users of Redhat . How many users of SuSE are there? Let's see. The number of Redhat versus SuSE posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 SuSE users. Mandrake posts on Usenet are about half of the volume of SuSE posts. Therefore there are about 700 users of Mandrake. Arecent article put Debian at about 80 percent of the *Linux market. Therefore there are (7000+1400+700)*4 = 36400 Debian users. This is consistent with the number of Debian Usenet posts.
Due to the troubles of Walnut Creek,abysmal sales and so on,Debian went out of business and was taken over by Gentoo who sell another troubled *Linux. Now Gentoo is also dead, its corpse turned over to another charnel house.
All major surveys show that *Linux has steadily declined in market share. *Linux is very sick and its long term survival prospects are very dim. If *Linux is survive at all it will be among *Linux hobbyist dabblers. *Linux continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, *Linux is dead.
*Linux is dying
Now which one of your EIGHT air bags will protect you when you roll over? Or when you get t-boned on the passenger side.
I thought about getting a new RX330 with a shitload of airbags but instead I decided to just give everyone that rides in my car one of those inflatable suits like from the Woody Allen movie Sleeper.
No. The patch lets the exec-shield be toggled off, and adds no more than 2-3 cycles per context switch. On a current x86 box running a vanilla 2.4 kernel, the maximum number of context switches per second is 100. That's a maximum of 300 cycles a second consumed. The oldest machine I've used running Linux was a 486/66 that a friend had. One of these can do at least 66 million cycles a second. On this elderly 486, there will be slowdown of less than a thousandth of a percent. Given that almost all major Linux applications are written in C, the security payoff is probably worth it. I value efficiency a lot, and even so the elimination of the largest security issue in Linux for less than a thousandth of a percent of the CPU time seems like a pretty good trade.
May we never see th
They solve the problem of the target computer getting owned.
The target daemon/service will probably crash, but you won't have to rebuild the computer from backups or from scratch. This is a HUGE improvement.
The car is not totaled, it only went off the road.
Nothing to see here; Move along.
Whether an additional safety feature will make people even more confident is hard to say and more of a psychology question than an economics question.
Finally! A year of moderation! Ready for 2019?
Except in the US where they are designed to work without seatbelts. Well, kind of. The propulsion used is much stronger in an attempt to help those that don't wear their seatbelts (one of those "we can't force them to wear their seatbelts: they're Americans, they're free, but let's tack on some copyright changes" things).
The problem is, then, that air bags in the US actually become more dangerous when seatbelts are used, but there is no evidence to suggest that they help those that don't wear them any more...
So on Windoze API there is a nice little convenience method called VirtualProtect() where you can change the access permissions on individual pages of memory.
Since we're on the subject of pages and access and such, does such an API exist within Linux? Or, are Linux programs stuck with an all or nothing situation?
OpenBSD recently announced something similar. Are they in fact actually similar? Or are they just different approaches to the same problem?
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
.. are dependent on overwriting data structures with code in order to function at all. The ugliness of programs knows no limits, and there are bound to be hackers out there who, obsessed with function pointer arithmetic, see this as a "powerful feature".
xkcd is not in the sudoers file. This incident will be reported.
>Whether an additional safety feature will make people even more confident is hard to say and more of a psychology question than an economics question.
The question is, will the additional safety feature be used as intended, or will it have another purpose.
What I'm thinking here is seatbelts. Slow drivers wear them either because they're forced to, or because they don't want to die. Fast drivers wear them as restraints to keep them from sliding about in the seat and in front of the wheel.
Same thing with ABS. The slow driver gets it so they can stop without thinking in case of an impending accident. The fast driver gets it in case they're rounding a curve at too high a velocity and need to turn while braking (not that physics of the two mix whatsoever in this case).
With programmers, an exec shield will be used by cautious programmers as an enchanced security measure, whereas bad programmers will see it as a way out of their programming hell that won't get them fired (easily). All IMHO, of course.
As long as it isn't mandatory, it isn't a problem. I'm happy to have a car without ABS -- I need the shorter stopping distance conventional brakes provide me in the snow more than the ability to skid and swerve.
If you could be told what you can see or read, then it follows that you could be told what to say or think - BoC
I guess this takes care of the Linux kernel ptrace/kmod local root exploit. On unpatched <=2.4.20 kernels this will spawn a suid 0 shell.
I must admit that I don't think "bad programmers afraid to be fired because their code has a security flaw" as a large enough demographic to be worth worrying about. Good programmers make mistakes, and a little extra safety may lengthen the time between discovery (and hopefully disclosure) and exploit. Bad programmers will find a way to screw up either way, but probably not any worse than without the extra safety.
Finally! A year of moderation! Ready for 2019?
My 'day job' is programming on a mainframe. This is how they go about handling this.
:-). A code segment does not have to be read-only, but normally is. The only other 'trampolining' permitted is by using the EXecute instruction which allows you to execute one instruction in any segment. Executing (for example) a Jump instruction would be of little use to a cracker because the target address would automatically be in the segment referenced by B0.
16 'segments' (call them what you will) can be based (pointed to) at any one time, each by one base-register.
B0 points to code
B1 points to the stack
B2-B15 point to data segments.
If you want to point B0 to another executable segment, you have to execute CALL, GOTO or RTN (return
Yes, we can have buffer-overflows, but 'all' that happens is that other data is overwritten. This will usually cause the program to abort. It is even possible to organise things so that every routine has it's own discrete data-segments. If a routine then starts accessing data outside of the routine, it gets the equivalent of a Segfault. Obviously parameters/arguments are excepted from this, although there would also be a Segfault if a routine went outside it's caller's data-area.
Actually, the hardware allows a caller to restrict a subroutine's access to only the n bytes it actually passed over as an argument. The HLL implementations do not enforce this setting in any of the languages I use.
Segment attributes are from Owner-Read, Owner-Write, Owner-Execute, Other-Read, Other-W and Other-X. Segments also have a Sharing-Level which is: Activity, Program, Application and Exec/System. Exec/System is normally combined with Other-Access: None, Application is normally combined with Read+Execute.
How much damage is caused each year because the 32-bit I386 architecture cannot supply a reasonable security framework at a reasonable overhead? If the AMD 64-bit processors are capable of fixing this mess, then the GLIBC maintainers could start looking at (optionally?) allowing a safer implementation by separating Code and Data. If this incurs memory-overhead, server farms should be migrating to 64-bit processors anyway by the time such a feature became available. They could also always compile the libraries without that feature.
Mielipiteet omiani - Opinions personal, facts suspect.
there's always kernel mode linux if you like to live on the edge!
Damn I would hate that since I drive my car to the track. :(
my sig
Intel did not designed it correctly. They should have put 2 bits for Read, 2 bits for Write and 2 bits for eXecute access. These 2 bits per type of access should be the maximum ring number allowed to touch the page.
:-).
For example, a page could be data only if the Read and Write ring was 3, but the eXecute ring was 0. Then, only the kernel would be able to execute code in that page.
This scheme is very flexible: there can be read-only pages, write-only pages, exec-only pages, or any combination of the three. Furthermore, some pages could only be written/read/executed by rings other than 3, enhancing protection even further.
I guess now it's too late for this
i hope this gets included into the vanilla kernel - i was quite shocked to learn initially that while e.g. true 64 (formerly known as digital unix formerly known as osf/1) had a non-executable stack and linux didn't (which i now understand was a problem with x86 vs. alpha hardware, not linux in particular).
and i sure hope that the non-exec flag has been implemented on amd's and intel's 64 bit cpus.
Overhead:
---------
the patch was designed to be as efficient as possible. There's a very
minimal (couple of cycles) tracking overhead for every PROT_MMAP
system-call, plus there's the 2-3 cycles cost per context-switch.
What happens if an executable maps in more than 16mb of shared libraries? Will one of these libraries get mapped to NULL? Or will it forgoe security for actually working?
Yes and no. While in economic theory this is entirely valid, reality is slightly more complicated. The same argument is used against handing out condoms in schools, i.e., that handing out condoms in public schools, free access to birth control, and so on is going to decrease the marginal cost to having sex, thus leading to more sexual promiscuity.
This is true, but think about it just a little more. In situations such as this, people who are not going to have sex anyway are probably not having it due to restraints imposed by personal values, shyness, inability to get any, or whatever. Giving these people condoms is not going to induce them to have sex. By contrast, people who are going to have more sex because they suddenly have an endless supply of contraceptive devices are already having sex, and because the supply of contraceptives was what induced them to have more sex, they were probably having sex unprotected in the first place. Therefore, we're all better off.
The situation is similar here. The people who are going to write crappy code are going to write it anyway. Te people who are going to write decent code are going to write it anyway. What the nonexecutable stack patch protects us from is people who either write code that is crappy and don't care (e.g., risk-taking, dangerous drivers without regard for other motorists [or pedestrians when they're driving on the sidewalk]), and from people who write good code and just screw up (e.g., an accident).
BSD has a faster boot time.
This idiot pulled this right from that POS OSNews story about some lamer telling what he would do if he had his own Linux distro. Too bad he doesn't mention it's not even going to be a Linux distro.
Oh, and BSD *IS* dying.
What's interesting is when Redhat does things like this (funding kernel development and patches that benefit everyone), you don't hear a word from the same people who assosicate the company with Microsoft.
In SOVIET RUSSIA, the Internet logs onto You!
Then SBC/Yahoo! is part of SOVIET RUSSIA! Their ads claim that the Internet logs onto you!
One more crippling
bombshell hit the already beleaguered *BSD community when IDC confirmed that *BSD
market share has dropped yet again, now down to less than a fraction of 1 percent of
all servers. Coming on the heels of a recent Netcraft survey which plainly states
that *BSD has lost more market share, this news serves to reinforce what we've
known all along. *BSD is collapsing in complete disarray, as fittingly exemplified by
failing dead last [samag.com]
in the recent Sys Admin comprehensive networking test.
You don't need to
be a Kreskin [amazingkreskin.com] to predict *BSD's
future. The hand writing is on the wall: *BSD faces a bleak future. In fact there won't
be any future at all for *BSD because *BSD is dying. Things are looking very
bad for *BSD. As many of us are already aware, *BSD continues to lose market share. Red
ink flows like a river of blood.
FreeBSD is the most endangered of them all, having
lost 93% of its core developers. The sudden and unpleasant departures of long time
FreeBSD developers Jordan Hubbard and Mike Smith only serve to underscore the point
more clearly. There can no longer be any doubt: FreeBSD is dying.
Let's
keep to the facts and look at the numbers.
OpenBSD leader Theo states that there
are 7000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of
OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are
about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume
of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put
FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 =
36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.
Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out
of business and was taken over by BSDI who sell another troubled OS. Now BSDI
is also dead, its corpse turned over to yet another charnel house.
All major
surveys show that *BSD has steadily declined in market share. *BSD is very sick and
its long term survival prospects are very dim. If *BSD is to survive at all it will
be among OS dilettante dabblers. *BSD continues to decay. Nothing short of a miracle
could save it at this point in time. For all practical purposes, *BSD is dead.
Fact: *BSD is dying
One more crippling
bombshell hit the already beleaguered *BSD community when IDC confirmed that *BSD
market share has dropped yet again, now down to less than a fraction of 1 percent of
all servers. Coming on the heels of a recent Netcraft survey which plainly states
that *BSD has lost more market share, this news serves to reinforce what we've
known all along. *BSD is collapsing in complete disarray, as fittingly exemplified by
failing dead last [samag.com]
in the recent Sys Admin comprehensive networking test.
You don't need to
be a Kreskin [amazingkreskin.com] to predict *BSD's
future. The hand writing is on the wall: *BSD faces a bleak future. In fact there won't
be any future at all for *BSD because *BSD is dying. Things are looking very
bad for *BSD. As many of us are already aware, *BSD continues to lose market share. Red
ink flows like a river of blood.
FreeBSD is the most endangered of them all, having
lost 93% of its core developers. The sudden and unpleasant departures of long time
FreeBSD developers Jordan Hubbard and Mike Smith only serve to underscore the point
more clearly. There can no longer be any doubt: FreeBSD is dying.
Let's
keep to the facts and look at the numbers.
OpenBSD leader Theo states that there
are 7000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of
OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are
about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume
of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put
FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 =
36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.
Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out
of business and was taken over by BSDI who sell another troubled OS. Now BSDI
is also dead, its corpse turned over to yet another charnel house.
All major
surveys show that *BSD has steadily declined in market share. *BSD is very sick and
its long term survival prospects are very dim. If *BSD is to survive at all it will
be among OS dilettante dabblers. *BSD continues to decay. Nothing short of a miracle
could save it at this point in time. For all practical purposes, *BSD is dead.
Fact: *BSD is dying
In Louisiana and Mississippi, some of the most backwards states in the US, seatbelts are required by law.
What states don't require seatbelts?
Uh, forgive me, but there's a technology out there called "Java" that lets you do this right now.
-nate
One more crippling
bombshell hit the already beleaguered *BSD community when IDC confirmed that *BSD
market share has dropped yet again, now down to less than a fraction of 1 percent of
all servers. Coming on the heels of a recent Netcraft survey which plainly states
that *BSD has lost more market share, this news serves to reinforce what we've
known all along. *BSD is collapsing in complete disarray, as fittingly exemplified by
failing dead last [samag.com]
in the recent Sys Admin comprehensive networking test.
You don't need to
be a Kreskin [amazingkreskin.com] to predict *BSD's
future. The hand writing is on the wall: *BSD faces a bleak future. In fact there won't
be any future at all for *BSD because *BSD is dying. Things are looking very
bad for *BSD. As many of us are already aware, *BSD continues to lose market share. Red
ink flows like a river of blood.
FreeBSD is the most endangered of them all, having
lost 93% of its core developers. The sudden and unpleasant departures of long time
FreeBSD developers Jordan Hubbard and Mike Smith only serve to underscore the point
more clearly. There can no longer be any doubt: FreeBSD is dying.
Let's
keep to the facts and look at the numbers.
OpenBSD leader Theo states that there
are 7000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of
OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are
about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume
of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put
FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 =
36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.
Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out
of business and was taken over by BSDI who sell another troubled OS. Now BSDI
is also dead, its corpse turned over to yet another charnel house.
All major
surveys show that *BSD has steadily declined in market share. *BSD is very sick and
its long term survival prospects are very dim. If *BSD is to survive at all it will
be among OS dilettante dabblers. *BSD continues to decay. Nothing short of a miracle
could save it at this point in time. For all practical purposes, *BSD is dead.
Fact: *BSD is dying
From a physics point of view: The marginal value must be that one gets from A to B faster (ignoring any potential adrenaline addiction as a motive). This is a linear equation where d = vt (d = distance, v = velocity, t = time; I don't know what letters are using in English). The cost can be expressed as the kinetic energy, or E = 1/2m(v^2).
The problem is that the value is a linear equation, while the cost is exponential. So, you get linear value but exponential cost.
Anyone agree?
It would seem to me that it's clear this patch is much more than just a non-executable stack patch. I think an important point is that while it isn't perfect, if this becomes a standard part of Linux then we can stand on the shoulders of this and tackle the next set of problems. Eventually we may get there.
If we wait until a perfect patch presents itself we will never get there. F.E. using this patch will bring to light all applications that require gcc trampolines. With time, perhaps all of the trampoline code will be replaced - several articles have been written on how to live without trampolines, perhaps this would be the push needed to change.
Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ (Java Web Startable)
Why was this patch released under OSL/GPL license? I've seen some other bits from RedHat (employees) released under non-GPL license, although I clearly remember their CTO saying a couple of years ago that they will do only GPL software.
I downloaded the Wine sources and it appears that Wine DOES call mprotect() followed by some memset into a page table(?) Apparently mprotect() does work on x86 processors. (or does it?)
note to moderators: linux bashing is only wrong when it's lies.
A point which was apperantly well understood by the person who modded this troll down.
I don't know what you are referring to. Logging in as root is no different from running a program with "su" or "sudo"--you can screw up your system in the same way. And using X11 as root is also fine--any reasonable X11 installation will default to local-only, UNIX-domain connections, making it as secured as any other root-owned resource on the system.
Logging in as root is the traditional way to administer UNIX systems, and it's still perfectly fine.
This would be a good time for TASK_UNMAPPED_BASE to become an inherited parameter controlled by setrlimit/getrlimit. It would also be a good time to get a binary structure interface to /proc/self/maps, much like VirtualQuery in Win32.
Programs compiled for the x86 architecture may well assume that they don't have to set the executable bit on pages because the hardware doesn't support it anyway. Whether such programs are "correct" or not, this patch may break applications.
While of course all of our software should be correct, using the Operating System to make software more robust is almost always a good thing.
You know, that's the very same thing that Microsoft does every day, and yet your praise Linux for doing it, and condemning Microsoft. That is what I most find interesting about this community...
-Chris
Well, assuming you are serious, and this isn't just a troll.
1)I really don't ever recall anybody condemning Microsoft for making their Operating System more robust.
2)While obviously the general attitude on slashdot is anti-microsoft, this isn't the reason, and has nothing to do with why that is.
3)I would claim that a more robust OS, one that executes applications in greater isolation from one another is becoming more expected of System Administrators. Microsoft has been working on this for a while, and it is good to see Linux doing the same thing.
4)If you are going to post using HTML select HTML Formatted below your message, and click the preview button.
5)If you really think I have condemned Microsoft for making their OS more robust I would appreciate a link to the comment. thanx.
Well, since you asked...
Yes, the site came up fine for me. And I actually wasn't too worried about Red Hat's servers getting Slashdotted; I think Red Hat has pretty good servers.
And I wasn't even looking for free karma; I already have plenty.
I know that many, many people just read the Slashdot comments and never click through the links, and I wanted them to see the announcement before asking questions answered in the announcement. I was hoping to head off some of the more obvious dumb questions.
Also, the URL provided is for a very temporary place: Ingo's personal stuff. A year from now people might read the archived comments on Slashdot, and I thought it would be nice to have the announcement in there, especially because the link probably won't work anymore. (Although I may have been wrong about the link not working anymore; there seems to be lots of older stuff on there that he never took down. Oh, well.)
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
"Exactly true, and in some parts of Australia, there are laws prohibiting the use of full role cages and racing harnesses because they make a vehicle safer at high speed, thus enticing the driver to drive at a higher speed"
There is another economic aspect to this as well.
When I drive fast, I get all the benefit. However the risk is shared by other road users. This is the classic economic problem of externalities. Just as in pollution, the polluter gets the benefit, but everyone breathes the smoke.
This is not just theory. When they made seat belts compulsary here, more pedestrians died. The reason was that people drove faster and pedestrians were more likely to get hit, and got hit harder.
In a perfect world, I'd agree. But people are stupid. The average driver won't realize that cost increases exponentially in your example, and thus won't change his risk estimation accordingly.
My Sig: SEGV