Kernel Traffic Zack Brown
Security Virtual Memory Robert Dinse Gregory Maxwell Linus Torvalds Horst von Brand

Continuing the discussion from last week in , Robert Dinse reiterated that making the stack unexecutable, although not a perfect answer for security, would still help in a significant way. Horst von Brand pointed out that software was improving all the time, making buffer overruns more and more difficult for the "script kiddies". He added that most of the people trying to crack systems were using information that the real crackers had already shared with the community. He went on to say that a non-executable stack would only give people a false sense of security.

Robert agreed that absolute security was impossible, but reiterated that a non-executable stack was just another layer of security that should be there, along with root passwords etc; he agreed that software security fixes were happening, but added that protocols and features were evolving, introducing new bugs all the time. Steve VanDevender also replied to Horst, saying, You may as well argue that file permissions are unnecessary becase well-behaved programs and users won't mess with files they're not supposed to, and the existence of restrictive file permissions merely causes crackers to find ways around them.

He pointed out that if a non-executable stack were an option in the kernel, those who didn't like it would be free to not compile it in. Later, he added, I see a non-executable stack as being completely in line with all the other security partitioning and protection methods that are already in an operating system -- page protections and virtual memory partitioning so programs can't access or modify memory they aren't supposed to; permissions and user/group checks so programs can't access or modify resources they're not supposed to and users can't execute programs or modify files they're not supposed to, and so on. Many of these things could also be accomplished by careful coding in programs, but these protections are put into the operating system because programs cannot be universally trusted to play nice.

Theodore Y. Ts'o argued, The only reason why there are so many stack-smash attacks is because there are a couple of tools written to automatically analyze a particular binary to produce the exploit. Such tools could easily be modified by someone with a clue to simulate a valid trampoline code, or to find some incovenient location in the program to jump into. And, once those tools exist, we're back to sqaure one, except that there's more crap (that's now useless) in the kernel.

Later, he elaborated:

making the stack non-executable purports to solve a generic class of problems involving stack overruns. The fact is, it doesn't. Fundamentally, the real problem is the fact that the program allows an automatic array variable to be overrun, and allow the stack to be smashed.

Suppose an attacker find a stack overrun in sendmail and the stack is executable; he just simply sends data which overwrites the return location on the stack, and contains the code to run execv("/bin/sh"). If the stack is made non-executable, then all the attacker needs to do is find some place in the sendmail text where the instruction "call execv" lives. He then overwrites the arguments area of the stack with the desired arguments of execv, makes the return address point to the "call execv" instruction, and then when the function returns, control is transfered to the "call execv" instruction, which then in turn transfers control to the execv code in libc, and we're off to the races.

So making the stack non-executable didn't stop the attack! It changed the method by which the attacker might need to exploit a stack smash, but that's about it. And once someone writes a tool to automatically analyze a binary to find vulnerable places where a stack smashing attack can transfer control into a victim program's text area, then any advantage making the stack non-executable is well and truely gone. At best, making the stack non-executable is really only a security-through-obsecurity kind of thing. It will stop stupid hackers.... temporarily.... until they adapt their methods to attack the very same holes they are attacking today.

It's like putting antibiotics into chicken feed. It might temporarily decrease the spread of certain types of bacteria in improperly cooked food, but in the long run, the bacteria develop resistance, and then we're back where we're started. And you'll notice that scientists have made the argument that it's better not to put antibiotics in chicken feed if it isn't going to stop the bacteria in the long run. This is a similar situation.

A very frustrated Gregory Maxwell accused Ted of intentionally confusing the issue. He pointed out that certain attacks were simply impossible if the nonexecutable stack patch were applied. But he decided to just port the patch to 2.3.x and continue the argument at that time.

The argument continued through various threadlets there and elsewhere, with some hotspots. Linus Torvalds has apparently already decided not to put the patch in his tree, and he didn't have anything to add to that in this discussion.

David S. Miller

Someone pointed out that the date of the linux-kernel digest for January 3, was "January 3, 19100". A couple people pointed out that this was a bug in Majordomo, and the next day David S. Miller reported that the problem was apparently fixed. Rafael E. Herrera added, The code generating the date is appending the "number of years since 1900" to "19". The code may be using the tm structure from time.h -- see localtime(3)

Victor Khimenko David S. Miller

Alexandre Hautequest couldn't seem to find any RARP support in 2.3.35, though it had been in previous kernels. David S. Miller explained that it was really a userland idea, and had been taken out of the kernel. He added that a userland version was in development. Alexandre wondered why it had been taken out of the kernel before the userland app had been developerd, but Derrick J Brashear, also replying to David, gave a pointer to an existing userland version. Victor Khimenko gave an additional pointer, and pointed out that the userland RARP tool had been available for at least a year, well before its removal from the kernel.

FS: NFS Matthew Kirkwood Rik van Riel

Someone asked what would happen if the NFS server of an NFS-mounted swap partition went down Actually, as Martin Stromberg pointed out to me, swapping over NFS uses a file, not a partition. Thanks, Martin!. Would it cause a kernel panic? Rik van Riel replied that an NFS mounted swap partition made sense for diskless clients, and perhaps for other situations as well, and added that he wouldn't expect a panic, although most of userland would probably die. At first, Brett Person seemed to be able to confirm this from experience, but Gregor Suhr pointed out that Brett's situation (a broken partition writing bad swap data) was not applicable to the case of an NFS-mounted swap partition going down. In fact, Peter Sasi disagreed with Rik entirely, saying, In theory (because NFS is a stateless service) clients will just wait, and when the server comes back online, they just continue. Matthew Kirkwood pointed out that this was only true with a hard mount, and Alan Cox came in with, For reference. SunOS 4 hard mounts wait, soft ones are killed with a bus error.

FS: ext2 Daniel Phillips Jamie Lokier

In the course of discussion, Jamie Lokier suggested having a new buffer state: "dependent dirty", which would be neither flushed nor dirty, but would be linked to from an ordinary dirty buffer. Once that dirty buffer was flushed, the dependent dirty buffer would be marked as dirty. This would give a partial order to disk writes (which in turn would help folks like Daniel Phillips with his integrity-preserving variation of ext2fs). Stephen C. Tweedie replied, We've talked about this sort of thing in the past. Linus is quite interested in the possibility of adding write ordering for pending writes or to the writeback queues, but really wants the buffer cache to lose, not add, functionality. Adding more complexity to the buffer cache for cases like this just isn't going to be accepted.

Mike A. Harris pointed out that projections of kernel release dates were invariably wrong. He added, everyone including Linus agreed that the release cycle for 2.2 was WAY too long, and I remember reading that the 2.3->2.4 cycle would indeed be MUCH shorter. Linus wanted the 2.4 kernel out quickly, and last March or so, it was said that the 2.4 kernel was scheduled for release in Fall 1999. This was later relegated to be "hopefully before Christmas", and now the last that I've heard is "Sometime in Q1 2000". He summed up his point, as, Do not project the major kernel release dates as it is bad press. It gets expectations up, and lets some people down. Even far speculation is bad because people will turn it into a serious release date. So saying "maybe by the end of the year" will be turned into "oh it is definitely coming out by the end of the year" by someone else".

Alan Cox replied, Its a target. If you dont have a target you never finish. If you do have a target you miss it sometimes. The good thing is we are missing by a smaller margin each time. This made sense to Mike.