The details on loading rootkits via /dev/mem

[Posted April 16, 2009 by corbet]

For the curious, here is the paper describing rootkit injection via /dev/mem [PDF]. As expected, there's not a whole lot that's truly new, though there are some clever techniques for getting the kernel to allocate memory for the injected code. The authors note that, indeed, the STRICT_DEVMEM configuration option will block this attack. "Until recently there was no protection inside the kernel main- line, although SELinux has limited seeks above the first megabyte of memory for a few years. Users of RHEL and other distributions have been safe for some time now."

to post comments

I would not feel safe

Posted Apr 16, 2009 22:20 UTC (Thu) by proski (guest, #104) [Link] (1 responses)

Users of RHEL and other distributions have been safe for some time now.

I would not feel safe if somebody has root access to my system but cannot use /dev/mem to install a rootkit. /dev/mem protections are beyond the last line of defense. To continue the military analogy, it's an officer's pistol. If it has to be used against enemies, things are very bad already.

That's not to say that strict /dev/mem is not worth the trouble. It protects against other things as well, such as buggy local software.

I would not feel safe

Posted Apr 19, 2009 4:36 UTC (Sun) by maco (guest, #53641) [Link]

Nevermind that the "users of RHEL" comment only applies to the ones that keep SELinux enabled.

"Protected" -- for how long?

Posted Apr 16, 2009 23:11 UTC (Thu) by spender (guest, #23067) [Link] (16 responses)

By "some time now" he must mean 3 months, since it was trivially bypassed by using mmap instead of read/write for the 6 months prior to that (since 2.6.26 when it was CONFIG_NONPROMISC_DEVMEM). See: https://bugzilla.redhat.com/show_bug.cgi?id=460857
As you can see, that vulnerability was only found and fixed because it was being actively exploited in the wild by a rootkit (so much for Linus' "if we don't tell the bad guys about the bugs, they'll never find them").

Compare that to the 7 years grsecurity has protected against this. Not only that, but as the PaX team pointed out in the other thread, the current code is still wrong.

It seems to be a recurring problem: security concepts that get adopted from PaX/grsecurity are never implemented correctly on the first or second try. Remember the NULL pointer dereference "protection" which was bypassable for 6 months via expand_stack and other privately disclosed methods? Or the weak ASLR added since 2.6.12 (that's 4 years ago) where only last month did it become public that the "randomized" bases were trivially obtainable locally via /proc (and there are still methods that aren't fixed). grsecurity had that closed for 7 years as well.

-Brad

"Protected" -- for how long?

Posted Apr 17, 2009 1:01 UTC (Fri) by tialaramex (subscriber, #21167) [Link] (15 responses)

That's an interesting Linus quotation you have there. Turn about is fair play, right ?

"PaX is completely broken, no-one should use it" Brad Spender

"Protected" -- for how long?

Posted Apr 17, 2009 1:19 UTC (Fri) by spender (guest, #23067) [Link] (13 responses)

You don't need to be disingenuous; you were around when the discussion regarding the kernel developers' official policy of silently fixing vulnerabilities was discussed. You are well aware of their policy and Linus' reasons for it.

Yes. Because the only place I consider appropriate is the kernel
changelogs, and since those get published with the sources, there is no
way I can convince myself that it's a good idea to say "Hey script
kiddies, try this" unless it's already very public indeed.
http://thread.gmane.org/gmane.linux.kernel/701694/focus=7...

If you haven't been at a univerisity, you don't know how many smart young
people want to "try it to see".
http://thread.gmane.org/gmane.linux.kernel/701694/focus=7...

Torvalds also says he doesn't care for labeling updates and changes to Linux as a security fix in a security advisory.
http://www.cio.com/article/444075/Torvalds_Calls_OpenBSD_...

"I believe that 'security through obscurity' can actually be one valid level of security (after all, in the extreme case, that's all a password ever really is)," Torvalds wrote.
http://www.internetnews.com/dev-news/article.php/3458961

But congratulations on completely ignoring the content of my post with your worthless reply.

-Brad

"Protected" -- for how long?

Posted Apr 17, 2009 9:44 UTC (Fri) by hppnq (guest, #14462) [Link] (5 responses)

The STRICT_DEVMEM design and implementation is not without discussion among kernel developers. Unlike with other systems, the Linux kernel development process allows turds as well as gems to be entered into mainline without them being polished completely. That's the way it works. You see this a lot where people are cooperating.

Of course this has benefits as well as downsides, but you seem to be hinting that this must mean that Linux systems are unsafe, or less safe than they need be. This would very obviously not be true, for the simple reason that unauthorized access to /dev/mem is not completely dependent on a sane implementation of STRICT_DEVMEM. Or it should not be.

In your quoting you seem to miss one important part of Linus' point of view: that it may be a good idea to simply fix all bugs instead of singling out a certain class of them as being more important by nature.

Borrowing your logic: if there is a flaw in the implementation of STRICT_DEVMEM, there is also a flaw in the published attack. I think that demonstrates nicely how the process works.

"Protected" -- for how long?

Posted Apr 22, 2009 23:25 UTC (Wed) by dersteppenwolf (guest, #58226) [Link] (4 responses)

"Unlike with other systems, the Linux kernel development process allows turds as well as gems to be entered into mainline"

This would be great marketing tagline for Red Hat. But I hope you realize the flawed logic behind this reasoning. Let's imagine for a second that PaX was a turd, and ExecShield a gem, or viceversa (depending on your touch with reality and experience on security matters and system internals). Why the integration of some of the PaX features was never considered for mainline?

I'm not talking about the segmentation-based approach to NX, which could have understandable drawbacks for inclusion. But, what about the other gazillion advances PaX has implemented a decade ago and everyone has been slowly, but steadily plagiarizing? (yes, you read that right: plagiarizing. The act of copying someone else's work without giving proper credit or obscuring it for one's self promotion).

Further more, "Linux systems are unsafe, or less safe than they need be" implies you mix an objective sense of security with your perceived one. Let's say that the child pornography collection of some pedophile in Thailand does not have the same security impact as the manuals for operating a military beacon. And I agree, but the problem is that Linux is unsafe because of managerial decisions taken by people who don't have the necessary background, understanding and acumen to make them. Just because Linus is a demigod among hippies does not make him a kernel security nutcase.

I won't go into greater depths to demonstrate that your logic is the actual flawed one, besides the seemingly sheer power you have for squeezing a handful ad hominem fallacies in such a short text.

Linux, so good it smells. If you drink the koolaid, it might go away.

"Protected" -- for how long?

Posted Apr 24, 2009 14:50 UTC (Fri) by hppnq (guest, #14462) [Link] (3 responses)

This would be great marketing tagline for Red Hat.

Even though in this very first sentence you reveal that 1) you do not understand the Linux kernel development process, 2) you do not understand the Red Hat business model and 3) you did not understand my comment, you still managed to surprise me with the rest of your comment.

"Protected" -- for how long?

Posted Apr 27, 2009 17:36 UTC (Mon) by dersteppenwolf (guest, #58226) [Link] (2 responses)

You are right, I don't really understand the business model behind Red Hat. It's quite a challenging thing to understand how a corporation gets away with making a profit from the work of helpful and altruist volunteers world-wide.

And in a similar path of reasoning, I don't understand how Linux (especially 2.6) could end up being used in a corporate environment. With all due respect, it's a theme park version of an operating system core. The rollercoaster gives you a huge thrill, but you throw up anyway.

Regarding your comment, It was indeed pretty awesome, man.

"Protected" -- for how long?

Posted Apr 27, 2009 23:58 UTC (Mon) by nix (subscriber, #2304) [Link] (1 responses)

Thus speaks someone who's never seen high-end financial software used to
throw umpty-trillions around the world.

Believe me, Linux is a glittering icon of perfection next to most of
*that* appalling grot. (I don't even need to mention the major settlement
system whose core was for many years an umpty-thousand-line shell
script... but I'm going to anyway because I want to make you feel as ill
as I do.)

"Protected" -- for how long?

Posted Apr 28, 2009 3:07 UTC (Tue) by dersteppenwolf (guest, #58226) [Link]

Thanks for giving me cancer. Can we get back to discussing why Linux is flawed because their developers choose it to be that way? Even goddamn Vista is safer at the moment. That's kind of a shame.

misquoting

Posted Apr 23, 2009 12:32 UTC (Thu) by pjm (guest, #2080) [Link] (6 responses)

tialaramex may not have been very articulate, and may have ben more curt than courteous, but I think was trying to make a helpful point (which I hope you won't yourself completely ignore, if I can explain it better).

There is quite a distance from Linus words that you now quote (expressing a belief that explicit changelog entries lead to more attacks by relatively casual attackers such as curious university students) to if we don't tell the bad guys about the bugs, they'll never find them.

It is helpful to look into the costs and benefits of various approaches to drawing attention to security flaws. It is helpful to point to this as one data point towards establishing to what extent the current approach to changelog entries is effective in reducing attacks. (Of course one data point isn't enough to show that it doesn't reduce attacks, but does give some information.)

Whereas misrepresenting someone's position in such a way as to give the false impression of having disproven their position (straw man tactics) is not helpful, and is both harmful to establishing the right answer to the question under consideration, and is also objectionable to the person being misquoted (as tialaramex tried to demonstrate with a fairly extreme example of misquoting).

I understand that you may not have intended to apply a straw-man approach, but the effect is the same. So the point is, be careful in representation or attributing quotation to someone.

I hope you find this not a worthless reply, when explained more carefully.

misquoting

Posted Apr 23, 2009 23:21 UTC (Thu) by PaXTeam (guest, #24616) [Link] (5 responses)

if you took this much time to explain what seemingly you failed to understand yourself, you might as well have done some further reading on the subject and saved some time here. i'll draw your attention to http://marc.info/?l=linux-kernel&m=121617056910384&... and its parent post http://marc.info/?l=linux-kernel&m=121616990509661&.... read them and understand where Linus drew the line: covering up the security impact of bugs for good. no ifs and buts, it's there in plain and clear text. what spender quoted may not have been the most descriptive to the subject matter but anyone who followed last summer's flamewar knows what it was about and how it concluded. in short, do your own research before educating someone on misrepresentation.

misquoting

Posted Apr 24, 2009 13:09 UTC (Fri) by pjm (guest, #2080) [Link] (4 responses)

I'm puzzled by your reply. Are you sure you're responding to something I've said? Do you feel it negates something I've said?

misquoting

Posted Apr 24, 2009 14:27 UTC (Fri) by pjm (guest, #2080) [Link] (3 responses)

For example, do you think that it wasn't a misrepresentation of Linus' position, or do you think it merely not important enough to take issue with? If the latter, then there's nothing more I can say on the issue.

misquoting

Posted Apr 25, 2009 1:29 UTC (Sat) by PaXTeam (guest, #24616) [Link] (2 responses)

> For example, do you think that it wasn't a misrepresentation of Linus' position

exactly. i even gave you the links to the thread where you can read about it yourself. have you?

misquoting

Posted Apr 25, 2009 12:36 UTC (Sat) by pjm (guest, #2080) [Link] (1 responses)

Oh good, now I know a bit more about where our differences are. The next thing to know is whether it's because we disagree about what Linus' position is, or whether we agree on the position but disagree about whether or not the words in quotation marks are a sufficiently close approximation to that position.

(I'll continue to spend some more time and space on this partly just for my own curiosity, and partly because there's a slim chance that exploring this might actually lead to a slightly better understanding of Linus' position; and maybe you'd like to understand why I or tialaramex have posted as we have.)

First of all, the easy case: has Linus literally said the words if we don't tell the bad guys about the bugs, they'll never find them ? I'd guess the answer is no, as this doesn't occur in the messages that you or Brad refer to, and a google search doesn't find it [other than here on this thread in LWN], and google does seem to find most other linux-kernel discussion; but maybe he said it in a different forum I'm not aware of that isn't indexed by google. If so, then that would clear things up straight away.

(Btw, I understand and even appreciate you asking to check with your correspondant that they have read the posts linked to: I know it's frustrating to discuss with someone who isn't actually giving thought to what you're saying. So yes, I had read the two posts you linked to, and also the posts that Brad referenced above and some of the surrounding posts, and I remember some of the discussion from when it last came up; though obviously I wouldn't be as closely familiar with the discussion as you and Brad, so thanks for having taken the time to post links to the relevant posts.)

Otherwise, do you believe that Linus either believes or has said that withholding information from commit messages will mean that no bad guy will know about any bug, or that no bug in Linux will be exploited in the wild ? (As distinct from believing merely that withholding information from commit messages will reduce how many bugs bad guys find out about, or reduce how many bugs will be exploited in the wild.)

Otherwise, do you think that there's no significant difference between saying "... then they'll never find them" and saying "... then fewer bad guys will ever find them" ?

There are some other possible reasons for our differing, but the above questions will do for now, if you too would like to continue to look into this. (I'll understand if you choose not to spend any more time on it.)

misquoting

Posted Apr 25, 2009 19:14 UTC (Sat) by PaXTeam (guest, #24616) [Link]

the easy case: think 'paraphrase' (as far as i know, that is. what went on in private discussions is unknown of course, but the public posts speak for themselves, see more on this below).

for what to read: it's not only about the few posts we linked to, it's the entire flamewar on lkml and some 5 threads here on LWN, hundreds of posts altogether. i understand if you're less than inclined to read them though, but then don't expect me to repeat all what was said back then either (much to the delight of many readers i guess ;).

as for your other questions: i assume you're not involved in computer security which would expain why you missed the real meaning behind spender's quote. in short, it was slyly disparaging as Linus' publicly stated position and actual actions are so much disconnected from reality (it's not a matter of my or anyone's belief, it's of public record, so much so that it earned him this nomination last summer: http://pwnie-awards.org/2008/nominees.html#lamestvendor).

let me leave you with some food for thought: imagine someone with the ability to write exploits against kernel bugs. imagine further he can also determine just by looking at a given patch whether it fixed a (potentially) exploitable bug (potentially, since one cannot be sure until one actually tries it, kernel bugs usually aren't the easiest kind to exploit). now imagine that you give this person a list of patches without telling him what they do. do you actually believe that this will prevent him from picking out the ones fixing exploitable bugs? because that's exactly what Linus et al. have tried to argue in their desperate attempt at explaining why coverup is good. last but not least: imagine that a file system driver has a bug that can corrupt on-disk data. do you think the proper approach is to not tell the world about it? history says otherwise. now imagine you have a kernel memory corruption bug that can do the same by virtue of corrupting filesystem (meta)data (let's forget about the potential for privilege elevation). do you think it's prudent to not tell the world about it and vehemently argue why it is even a good thing? history says yes. now consider that a memory corruption bug is typically much easier to abuse for trashing random memory (including the filesystem stuff i mentioned) than it is to properly and reliably exploit for privilege elevation. as i said, just some food for thought...

"Protected" -- for how long?

Posted Apr 22, 2009 23:10 UTC (Wed) by dersteppenwolf (guest, #58226) [Link]

With all due respect, you should really hire a humor coach as soon as possible.

The details on loading rootkits via /dev/mem

Posted Apr 19, 2009 11:09 UTC (Sun) by const-g (guest, #5006) [Link] (42 responses)

We have at least passed 3 years since both the CPUs and Linux kernel support executable but read-only memory and shipped distribution kernels configure executable kernel memory as read-only. We also have the same period when syscall table (and other interrupt tables) are set read-only by compilation or by kernel code itself during boot.

I assume that the write() routine of /dev/mem does not set read-only memory as writable and a fault will take place during attack described. Thus, this attack is rather impractical. To use /dev/mem or /dev/kmem, one has to find a way to change writable memory (which will be data and not executable code) in such a way that it will cause kernel to run a desirable code with predictable results. While the kernel lacks data constraints checks in most places (usually assuming that safe and verified code runs), it is not an easy task. At least not as easy as the authors make it sound.

Of course if module interface is available, one can load a malicious code that can set arbitrary memory as both writable and executable. There are even (usually un-exported but obtainable via System.map or /proc/kallsyms) kernel functions that will do it for you. Using module interface is much more practical to achieve the result described in the article. This is how "security" products that modify syscall table with their own callbacks work.

The details on loading rootkits via /dev/mem

Posted Apr 19, 2009 22:03 UTC (Sun) by spender (guest, #23067) [Link] (40 responses)

Read IA-32 Software Developer's Manual Volume 3, Chaper 3. Learn about the difference between physical and virtual memory, and then you'll see why your post makes no sense.

-Brad

The details on loading rootkits via /dev/mem

Posted Apr 21, 2009 18:25 UTC (Tue) by const-g (guest, #5006) [Link] (39 responses)

Look at the source of drivers/char/mem.c.

The offset of the file (physical address) is converted to virtual address and copy_to_user() to that address is used for write call (this is done for kernel addresses, user addresses are treated differently).

Write a kernel module and try to modify the kernel address for syscall table or any executable area (like prtink() or whatever). You will get an OOPS or panic (depending on the context) because these areas are write protected for modern setups. The same with /dev/mem.

The details on loading rootkits via /dev/mem

Posted Apr 22, 2009 18:36 UTC (Wed) by spender (guest, #23067) [Link] (38 responses)

Protection of memory only exists in the context of a given set of page tables, which also provide the virtual->physical address mapping.
So, if you write a kernel module to do that, it OOPSes because you're using the same set of page tables referencing those virtual addresses as the rest of the kernel is using. Since these page tables have the protection bits set on them to disallow writing, direct attempts to modify them causes an exception (if CR0.WP is set -- do you even know what that is?). When you open a file for read/write, you are able to read/write to it. This is no different with /dev/mem. When you mmap a file for read/write (you have to specify the offset and length as well) and are given permission to do so, you are able to read/write to it. This is no different with /dev/mem. You've obviously never written any code that actually uses /dev/mem. You coupled your experience with using the normal page tables through a kernel module and tried to extrapolate it to something where it doesn't apply.

Now do what I suggested earlier and read Chapter 3 of Volume 3 of the Intel manuals and stop trying to be a smart ass. Or you can continue to post about things you have no knowledge or experience with and embarrass yourself further; your choice.

-Brad

The details on loading rootkits via /dev/mem

Posted Apr 22, 2009 20:00 UTC (Wed) by const-g (guest, #5006) [Link] (37 responses)

I have commented on approach described in the article. In all examples that they give they use write() or read() calls to /dev/mem file descriptor.

And write() simply translates offset to virtual address and mem-copies. Thus it will surely segfault.

I do agree that since /dev/mem device has memmap() callback defined, you can use the mmap() operation to create a new mapping with new protections. This would work except that this callback does range checking in modern kernels and restricts the range you are allowed to modify. As other people have commented this has been the situation for a long time already.

I do know what I am talking about (I have written code that patched running kernel modifying page fault handlers and system call table to do neat things) and you are simply an abusive ass.

The details on loading rootkits via /dev/mem

Posted Apr 23, 2009 0:00 UTC (Thu) by spender (guest, #23067) [Link] (2 responses)

"Thus it will surely segfault." -- Are you 100% sure about that?
Let's ignore for starters that the process doesn't segfault, the kernel OOPSes and the process is terminated with SIGKILL.
In fact, in reference to your assumption that the syscall table is read-only on x86, you're being fooled by the fact that it exists in the ".rodata" section of the kernel. The .rodata section isn't read-only at all, unless CONFIG_DEBUG_RODATA is enabled. Maybe it's the case that on your distro, that option happens to be enabled in the kernel. I just took a look at the kernel config for the latest Debian kernel. CONFIG_DEBUG_RODATA is disabled. It seems to be enabled however on RHEL/CentOS kernels. I haven't bothered to examine others.

Mr. Lineberry mentions that his technique doesn't work against RHEL, which is why he had to compile a custom kernel to demonstrate it. Note that I'm not praising Mr. Lineberry or his technique at all -- in fact his work is essentially plagiarized and provides nothing new (remove subtracting 0xc0000000 from virtual addresses and you have the exact same rootkit published in Phrack in 2001).

But you weren't purely talking about Mr. Lineberry's technique, as you made the blanket statement:
"To use /dev/mem or /dev/kmem, one has to find a way to change writable memory (which will be data and not executable code) in such a way that it will cause kernel to run a desirable code with predictable results. While the kernel lacks data constraints checks in most places (usually assuming that safe and verified code runs), it is not an easy task. At least not as easy as the authors make it sound."

This is just completely false and nonsensical. If for a given virtual address in kernelspace, it happens to be marked as read-only (so CONFIG_DEBUG_RODATA is enabled), it does not at all follow that it's impossible to write to the memory or that the attacker is stuck with only writing to "data and not executable code" so as to "cause [the] kernel to run a desirable code with predictable results". There are a number of different approaches, but the most obvious is to simply modify the page table entry associated with the virtual address the attacker is attempting to modify. To do this, a review of the code of set_pte_vaddr and the exported swapper_pg_dir symbol would be of use. If you actually knew as much as you think you know, I wouldn't have to generate these scenarios for you.

As for mmap checking and your definition of a "long time" I would simply refer you to my first post in this thread, which you must have glossed over.

In summary: do what I suggested initially and read the Intel manuals. Really. Or keep writing posts on the subject: I know of at least one rootkit author who's getting a kick out of them.

-Brad

The details on loading rootkits via /dev/mem

Posted Apr 23, 2009 8:15 UTC (Thu) by const-g (guest, #5006) [Link] (1 responses)

You wrote:

"There are a number of different approaches, but the most obvious is to simply modify the page table entry associated with the virtual address the attacker is attempting to modify. To do this, a review of the code of set_pte_vaddr and the exported swapper_pg_dir symbol would be of use. If you actually knew as much as you think you know, I wouldn't have to generate these scenarios for you."

This is what I meant when I wrote in my first post:

"Of course if module interface is available, one can load a malicious code that can set arbitrary memory as both writable and executable. There are even (usually un-exported but obtainable via System.map or /proc/kallsyms) kernel functions that will do it for you. Using module interface is much more practical to achieve the result described in the article."

Or are you claiming that you know of a "trick" to change page tables permissions by using io on /dev/mem (without mmap)?

I do not think /dev/mem has much longer to live. The drivers (Xorg) are encouraged to use /sys/.../resource files to map what they need and the need for /dev/mem will be eventually gone.

[root@constg ~]# pidof Xorg
2702
[root@constg ~]# cat /proc/2702/maps | grep /sys
a7fc4000-b7fc4000 rw-s e0000000 00:00 6798 /sys/devices/pci0000:00/0000:00:02.0/resource2
b7fc4000-b8044000 rw-s f8080000 00:00 6797 /sys/devices/pci0000:00/0000:00:02.0/resource0
b8044000-b80c4000 rw-s f8000000 00:00 6797 /sys/devices/pci0000:00/0000:00:02.0/resource0

The details on loading rootkits via /dev/mem

Posted Apr 23, 2009 12:52 UTC (Thu) by spender (guest, #23067) [Link]

You keep revising what you "meant" to say (forgetting the self-sufficient sentences that are just factually wrong, which no ex post facto revising can fix), and again your revisions are completely wrong.

You say "Of course if module interface is available, one can load a malicious code that can set arbitrary memory as both writable and executable."

Wrong again; module support isn't necessary to set arbitrary memory as both writable and executable. And yes, it can be done purely with read() and write() on /dev/mem as I've already said. You can call it a "trick" if you like, but if you did the reading I suggested it would be simply "textbook behavior."

Since you're clearly unwilling to educate yourself, there's no point really in wasting any more time with this.

-Brad

The details on loading rootkits via /dev/mem

Posted Apr 23, 2009 0:07 UTC (Thu) by dersteppenwolf (guest, #58226) [Link] (33 responses)

This sums up my feelings about this article and the comments: http://i40.tinypic.com/2rwubgy.jpg
If this site wasn't like a time capsule from 1980, images would be allowed to get posted for amusement.

The details on loading rootkits via /dev/mem

Posted Apr 23, 2009 14:00 UTC (Thu) by nix (subscriber, #2304) [Link] (32 responses)

It's also like a time capsule from 1980 in that the comments and responses are generally courteous. You and Brad Spender and a very few others are notable exceptions, alas.

The details on loading rootkits via /dev/mem

Posted Apr 23, 2009 20:11 UTC (Thu) by dersteppenwolf (guest, #58226) [Link] (31 responses)

I'm sorry if I've hurt your feelings, that wasn't my intention. I guess our ability to couple with hypocrisy and ineptitude is greatly diminished.

The details on loading rootkits via /dev/mem

Posted Apr 24, 2009 10:52 UTC (Fri) by nix (subscriber, #2304) [Link] (30 responses)

You've not hurt my feelings: you're just being pointlessly unpleasant. I
hope you don't think that being pleasant to people where possible is
equivalent to hypocrisy or ineptitude!

(shades of the Great Misogynism Comment Thread, yet again)

The details on loading rootkits via /dev/mem

Posted Apr 27, 2009 14:00 UTC (Mon) by Randakar (guest, #27808) [Link] (29 responses)

I find it interesting how PAX, spengler, and dersteppenwolf prove Linus's point for him. Every single sentence of theirs seems to be dripping with a mixture of arrogance and self-righteousness to the point where I have to check the author lines to see if it's not secretly one and the same person.

Want to know why the PAX patches don't go in and the useful bits are getting 'plagiarized'? Look no further. Linus has no interest in maintainers with an attitude like that and I don't blame him.

People have tried to tell them their narrow minded view of the world and their little security corner is not even nearly as important in comparison to the larger picture as they seem to think it is. Unfortunately the replies seem to demonstrate again and again that these people have made up their minds and are simply incapable of changing their views. The above discussion is a perfect example where the whole point of every reply made by spengler seems to be "I am smarter than you neener neener".

I don't know who's correct or who isn't. I don't care. What I do care about is "are people capable of working with others?". Being unable or unwilling to understand someone elses's point of view, being unable to refrain from calling discussion a "waste of time", purposely misquoting someone because "that's what I think he really said" - all of that evidence points to one answer: "No".

So you guys want to improve Linux kernel security? Good luck. You won't achieve anything with that attitude.

The details on loading rootkits via /dev/mem

Posted Apr 27, 2009 14:21 UTC (Mon) by const-g (guest, #5006) [Link] (1 responses)

Amen.

My thoughts exactly.

The details on loading rootkits via /dev/mem

Posted Apr 27, 2009 17:22 UTC (Mon) by dersteppenwolf (guest, #58226) [Link]

I absolutely agree too. Can we all just get along and let the good times roll?

The details on loading rootkits via /dev/mem

Posted Apr 27, 2009 23:47 UTC (Mon) by nix (subscriber, #2304) [Link] (17 responses)

It's 'spender', but seconded. If there's one thing a lifetime of
Asperger's has taught me, it's that social oil is completely *not*
pointless. Without it, it doesn't matter *how* bright you are: nobody will
pay any attention to you. More: if you've got it, many people (though not
Linus, thankfully) will pay attention to you *even if you're an idiot*.

So it behooves bright people (like spender) to *learn to be nice*. Then
people will listen to someone who's often right, and we're all better off.

The details on loading rootkits via /dev/mem

Posted Apr 28, 2009 3:22 UTC (Tue) by dersteppenwolf (guest, #58226) [Link] (16 responses)

From a fellow aspie survivor here: please stop being such an attention seeking drama queen over here. What the hell are you doing here, Mercedes?

BTW, you can use HTML for applying more dramatic effect to your seemingly invaluable contributions to this thread. It's a tad bit too complex to learn, at least for a technically illiterate person like me, but someone as intelectually gifted as you could surely get it working quickly. I really wish we could all just get along, have a nice discussion and finally make you realize that we are trying our best to help. But you guys keep getting angry over a technical issue, bringing all your anger and projecting your flaws and sense of self-worth unto us like if we just delivered a blowing strike of truth against your egos. Who knows, perhaps these fellows got something to say, and maybe they really aren't here to prove how experienced and skilled they are. Maybe they don't need your approval in that sense.

Perhaps they are just rather fed up with the fact that the entire community around the kernel has gone stupid about a simple fact: the current approach for security is mistaken and already had horribly laughable consequences.

Let me ask you something: if Linux was an actual closed-source product, commercial and backed up by a vendor who profits from its software sales, and not for selling support, bump stickers, hats, t-shirts and thongs with printed penguin logos, would the customers be willing to take the crap which is being done right now? Silent patching of remotely exploitable issues, local privilege escalation bugs, obscure architecture-dependent bugs, etc.

Why does Red Hat employ the person who stole the IRIX source code in the early 2000s? Stole as in DCC over EFNet, or so the rumor says. I would bet my earrings that SGI would be glad to talk about 'disclosure policies' with him on these matters...

The details on loading rootkits via /dev/mem

Posted Apr 28, 2009 5:04 UTC (Tue) by foom (subscriber, #14868) [Link]

Good job, you managed to fit insult, condescension, bitter contempt, mock helpfulness, and
rumor-mongering into your comment.

Quite an accomplishment. But if you want to continue in that vein, slashdot is over there...

The details on loading rootkits via /dev/mem

Posted Apr 28, 2009 6:20 UTC (Tue) by nix (subscriber, #2304) [Link] (12 responses)

Well done for proving my point, you offensive twerp. That's one of the
most gratuitously nasty comments I've read anywhere, ever. I don't know
who you are, but whatever code you've worked on I don't want to use: I
don't think it's trustworthy if its upstream guardians accept
contributions from someone as unpleasant as you.

I really really want an LWN killfile that I can use without switching to
firefox...

The details on loading rootkits via /dev/mem

Posted Apr 29, 2009 2:40 UTC (Wed) by dersteppenwolf (guest, #58226) [Link] (11 responses)

I fear part of my comment might be understandable only to a small subset of the readers here, or, the person itself who has been referred. It wasn't just IRIX by the way, although that's likely the least useful of his "achievements". Whether you believe this or not, sir, is moot.

Regarding your "I don't want to use your code" claim, I'll start a short run down on other offensive, troubled and criminal twerps that have successfully contributed to the Linux source code in the past decade:

- Hans Reiser (developer of the reiserfs filesystem, among other things), convicted of second degree murder of his wife, Nina Reiser, mother of two. He further argued she was involved in BSDM sexual activities and made the kids aware of them. Also, argued she was an alcoholic, besides having an affair with another man.Not only he murdered the mother of his children, he also tried to tarnish her reputation even after she was dead. One cool dude.

- Jon "maddog" Hall (instrumental on providing hardware and resources for Linus to finish the very first stable milestones of the kernel), with severe anger management issues which got him his nickname.

- The dozens of other political activists in there who could have an agenda of their own.

The list goes on.

The details on loading rootkits via /dev/mem

Posted Apr 29, 2009 3:09 UTC (Wed) by dlang (guest, #313) [Link] (10 responses)

Hans Reiser's contributions to the kernel were before his criminal actions (or do you claim that everyone should have known what he would do years later?)

but his attitude and actions had a _lot_ to do with the fact that his later work didn't make it into the kernel (sound familiar here?)

Maddog has been very nice and polite in my interactions with him, so whatever anger management issues that he has don't affect his interactions with the community.

as far as political activists, they keep their politics out of their techinical discussions (and when they don't they get slapped down)

of these examples, Hans is the only one who was really bad in his discussions, and that caused significant delays in any of his work getting added.

the examples that you guys are giving are as bad as Hans at his worst, and you think that people don't want to deal with you or your code (which would mean dealing with you as a maintainer) because they want linux to be insecure????? get real, they just don't want to deal with the abuse.

The details on loading rootkits via /dev/mem

Posted Apr 29, 2009 7:27 UTC (Wed) by nix (subscriber, #2304) [Link] (9 responses)

Actually dersteppenwolf is substantially worse. I've never seen any kernel
contributor act like dersteppenwolf is (maybe he's drunk?)

Hans's problem (er, contribution-related problem, not murder-related
problem) was the same as spender's, as far as I can tell: great
intelligence coupled with an inability to communicate with others without
being/appearing condescending and arrogant, or to adjust one's own
behaviour in response to feedback. It's a real shame... well, again it's
sort of moot in Hans's case, but in spender's, grsecurity is stuck in its
little bubble which rarely improves anyone else's code quality and isn't
very heavily used, when it *could* have improved the security of the
mainstream kernel for everyone. Unfortunately paxteam and spender blur
together in my mind, so I can't recall which of them it was who was
actually *complaining* on l-k, after the last marathon LWN thread, about
people taking ideas from his project and incorporating them into the
kernel while daring not to take the rest in one gigantic unreviewable
lump: no surprise that whichever project *that* was remains largely
ghettoized, then. (Doubtless I'll now get followups from both of them
saying "it wasn't me": guys, I don't care which of you it was.)

The details on loading rootkits via /dev/mem

Posted Apr 29, 2009 8:17 UTC (Wed) by dersteppenwolf (guest, #58226) [Link] (8 responses)

I'm krunk, not drunk. It's just too good that I've got diarrhea, so I can reply to all your substantially meaningless responses from the comfort of my toilet. Otherwise I wouldn't even bother replying.

Thanks sir, for proving yourself to be such an useless entertainment in my days of stomach infection solitude.

Meanwhile, could we get back to the topic at issue? Or choose some other one equally entertaining. How about talking about why kernel developers obscure vulnerabilities as denial of service issues when they are perfectly exploitable?

Regarding splitting up grsecurity and submitting patches to the maintainers, I think it was done in the past with hopeless results, but great attitude.

You know what, I just hope your personal information ends up splattered on some public site someday so we can all look back to this moment and laugh at your utter disregard and arrogance. You read that right. You most likely can't even grasp the nature of PaX or any of its concepts, yet you are here making claims about it. Guess that's why you resort to second guess and criticize the alleged attitude of its maintainer, who has more acumen in this area than any of us, and could possibly papa you about any system internals question.

With all due respect, please go fuck yourself. Now I'm gonna wipe my ass with pages printed from this thread and pray this diarrhea gets sorted out soon or I'll feel too tempted to delve deep into your innuendo. You goddamn pseudo grown up with the maturity and self stem of a 12 year old baboon.

The details on loading rootkits via /dev/mem

Posted Apr 29, 2009 9:01 UTC (Wed) by hppnq (guest, #14462) [Link]

How about talking about why kernel developers obscure vulnerabilities as denial of service issues when they are perfectly exploitable?

If you mean the SCTP one referenced on this page, it looks serious, but it is not "perfectly exploitable" in the real world. You may not (want) to understand this, but in general, people will try to make a realistic assessment of the actual threat -- developers, distributors and also a few serious security researchers.

In any case, security should be discussed and handled by people with at least some grasp of reality. Thinking that anyone can be on the right side of the thin line between right and wrong is part of the problem. It is typical that you don't understand this.

(The patch for the SCTP vulnerability was available last year, by the way. My distribution was updated some weeks ago.)

The details on loading rootkits via /dev/mem

Posted Apr 29, 2009 9:17 UTC (Wed) by nix (subscriber, #2304) [Link]

OK, so as well as being pointlessly insulting you can't read. I never said
that either PaX nor grsecurity were bad. I've used both and think they're
excellent pieces of work and that both the anonymous PaXteam and spender
are superb at spotting holes. They're just hopeless at the social-oil part
which makes it even slightly plausible that anyone else will pick up what
they do in any larger project.

(And, well, I had a dig. One comment during the 2.6 freeze, obviously
hopeless. An attempt by Valdis to split up the non-duplicative-of-LSM,
non-ASLR stuff in 2004: James Morris thought most the remaining bits were
of minimal security benefit (I agree with Valdis here: it's an extra bar,
so what if it's low, the cost is low too), but the thing had a BSD
advertising clause at the time so couldn't possibly go in. A thread in
2005 which foundered in flames, disagreements over worthwhile tradeoffs,
and claims (from a third party) that grsecurity was intrinsically
impossible to split up, which at a then size of 700K would make it
intrinsically impossible to ever merge. I've looked at every archived l-k
message ever to mention grsecurity, and there's no sign that anyone other
than Valdis ever tried to split it up at all.)

... sheesh, why am I even responding to someone whose idea of cogent
argument is poo jokes and threats of identity disclosure? I must be bored.

ENOUGH

Posted Apr 29, 2009 12:49 UTC (Wed) by corbet (editor, #1) [Link] (5 responses)

OK, this thread has gone well beyond anything useful. Please stop here. Now.

"dersteppenwolf": this is not the sort of commentary that is welcome on LWN. You are not the only offender here, but you've been pushing the boundaries. Please stop.

ENOUGH

Posted Apr 29, 2009 17:44 UTC (Wed) by nix (subscriber, #2304) [Link]

*Thank* you.

(I'll admit I suck at knowing when to stop, too. I'll shut up in this
thread as well.)

ENOUGH

Posted May 1, 2009 12:45 UTC (Fri) by dersteppenwolf (guest, #58226) [Link] (3 responses)

Corbet, please accept my most sincere apologies. I couldn't help it but defend myself against the obvious libelous and disrespectful attitude of this person and others, and felt morally obliged to comply with my ethical duties and present my personal perspective on these matters.

I did my best to try to get along and have a well mannered discussion here, but these people aren't the least interested on a civilized interaction. They come here with lies and banter, meaningless follow-ups which don't add anything of interest, but project their flaws and personal views in such a fascist way that any attempt to communicate with them ends in failure.

In addition, when they've been left out of arguments to support their claims, they resort to insulting people and calling them out as 'trolls'. I don't even know what they mean by 'troll' in this sense. Are they trying to make jokes about my physical appearance or disabilities?

Sigh, I had a better opinion of the Linux fan base until today.

ENOUGH

Posted May 1, 2009 13:26 UTC (Fri) by Los__D (guest, #15263) [Link]

o_O

Hats off. That must be the best "fake hurt"-playing I ever saw.

ENOUGH

Posted May 1, 2009 13:28 UTC (Fri) by corbet (editor, #1) [Link] (1 responses)

You're still doing it. I'm honestly uninterested in assigning blame for the direction of this discussion. Please let's just stop.

ENOUGH

Posted May 1, 2009 14:06 UTC (Fri) by dersteppenwolf (guest, #58226) [Link]

OK, I'm done with it as well. Like I said, I tried my best to get along.

BTW, is there any possibility in the future of allowing images to be included in comments? It would be quite beneficial in threads like this and some time ago It was impossible to put some diagrams on a SELinux related thread. Without those it's quite difficult to give proper explanations about some of the security models implemented (including MLS).

Keep up the great work with the site.

The details on loading rootkits via /dev/mem

Posted Apr 29, 2009 2:31 UTC (Wed) by k8to (guest, #15413) [Link] (1 responses)

Wow.

This is a new record in lows.

The details on loading rootkits via /dev/mem

Posted Apr 29, 2009 7:12 UTC (Wed) by nix (subscriber, #2304) [Link]

It looks kind of libellous to me. If RH were a UK company, or LWN were
hosted in the UK, with its libel laws (so harsh that even UK MPs think
they're crazy), I suspect Jon would have ripped the comment down for his
own safety. (At least I hope he would have.)

'dersteppenwolf' seems like a very alt.syntax.tactical-style troll name to
me, too.

The details on loading rootkits via /dev/mem

Posted Apr 28, 2009 4:19 UTC (Tue) by spender (guest, #23067) [Link] (6 responses)

Have some hashes:

spender@www:~$ md5sum ./devmem
6c8eb1e89e3e1a8c3bb207eecc517a20 ./devmem
spender@www:~$ sha1sum ./devmem
570b82139714e6640b9b1af02060e51de0558a9c ./devmem
spender@www:~$ date
Mon Apr 27 23:23:29 EDT 2009

See you in a couple years when someone figures it out. Unfortunately there's no one else involved in Linux kernel development who actually cares about improving security. They enjoy the mere appearance of security (the ability to claim they have ASLR and other protections), but don't bother to follow through. And that's why you end up with:

http://www.cr0.org/paper/to-jt-linux-alsr-leak.pdf
http://www.blackhat.com/presentations/bh-europe-09/Fritsc...

These have been public for weeks and are still unfixed. Whoever you think is in charge of the kernel's security is obviously asleep at the wheel.

I hope it's clear to everyone reading that objectivity doesn't matter to you: "I don't know who's correct or who isn't. I don't care." But instead, what's of utmost importance to you is that people "play nice."

Here's a better idea: if you don't have anything technical to offer, don't bother replying. If you know you're out of your element, don't bother replying, or just admit that you don't know what you're talking about. A person who's sitting on an exploit for the subject being discussed is unlikely to change his viewpoint.

-Brad

The details on loading rootkits via /dev/mem

Posted Apr 28, 2009 5:40 UTC (Tue) by patrick_g (subscriber, #44470) [Link]

>>> Whoever you think is in charge of the kernel's security is obviously asleep at the wheel.

Linux development is open. If nobody is in charge of the kernel's security why don't you take in charge this role? Of course you must learn to interact well with other in the community but patchs are very welcome.

The details on loading rootkits via /dev/mem

Posted Apr 28, 2009 6:24 UTC (Tue) by nix (subscriber, #2304) [Link] (4 responses)

Um, just checking. This is the person who was castigating the -stable team
for not releasing bugfixes until they could be sure if they were security
holes and they had working exploits, no matter how long it took, *and*
simultaneously that the holes existed in the first place...

... *posting hashes of descriptions of exploits rather than the fix*?!

Any claim you make henceforward that you're interested in *anything* other
than credit (that you're interested in, say, the security of the system or
any reduction in its count of security holes) should be considered in this
light. I'm convinced now.

The details on loading rootkits via /dev/mem

Posted Apr 28, 2009 12:47 UTC (Tue) by spender (guest, #23067) [Link] (3 responses)

You may disagree, but I choose not to contribute in such a way as if the people involved in Linux kernel development acted like other responsible companies who properly handle security. When you have exploits of your own, feel free to share them, but speaking for myself I refuse to support their policy of silently fixing vulnerabilities.

I will continue to do as I have done for the past 8 years and fix these issues within grsecurity. If the kernel developers are as capable as Linus claims to be able to backport silent vulnerability fixes, surely they can spot the fixes in grsecurity as well. The source is available to everyone, after all.

Regarding your summary of my view on how vulnerabilities *known to the developers* in the Linux kernel could better be handled, it's as wrong as it was last year when we corrected you on it. To say that I advocated "not releasing bugfixes until they could be sure if they were security holes and they had working exploits, no matter how long it took" is just pure trolling, and anyone who has read our past posts knows that. If you want to see how it can be handled (a little) better, see Chris Wright's announcement for the latest kernel.

-Brad

The details on loading rootkits via /dev/mem

Posted Apr 28, 2009 13:49 UTC (Tue) by hppnq (guest, #14462) [Link] (2 responses)

Instead you choose to foam at the mouth on a public news website, like, err, other responsible companies.

I am actually interested in your /dev/mem pagetable exploit, by the way. Just curious. Is it a bit like this, or are these people also hopelessly incompetent idiots who need to be taught a lesson?

The details on loading rootkits via /dev/mem

Posted Apr 28, 2009 14:27 UTC (Tue) by spender (guest, #23067) [Link] (1 responses)

If you're referring to this attack in Section 4.2 of the paper:

void remap_kernel_code() {
// Open /dev/mem device
fd = open("/dev/mem", O_RDWR);
// Map kernel code with RW access
// into user address space
user_mem = mmap(0, KERNEL_CODE_SIZE, PROT_READ|PROT_WRITE, MAP_SHARED,fd, KERNEL_CODE_ADDR);
// Overwrite kernel code
memset(user_mem, ATTACK_CODE_ADDR, ATTACK_CODE_SIZE);
}

This is the same method used by the Phalanx2 rootkit which was already discussed above. It's not the method the PaX team and I referred to, which as I've already mentioned needs only use read/write within the first 1MB of /dev/mem, as is allowed by the mainline protection.

But if you're talking about the one in Section 4.1, you're getting warmer.

Though it sounds like the solution provided in Section 5.1 would do the trick against the attacks in Sections 4.1/4.2 as well as our attack, there's also a much easier way to solve all three problems (since in a way, they're all facets of a single problem).

If you do the work to research it, given the details we've already mentioned, I'm pretty confident you can figure out the problem and how to fix it as well.

Completely unrelated, but somewhat "breaking" news: http://kernelbof.blogspot.com/
Hello reliable remote root compromise and disabling of SELinux!
As you can read in the link, this was a vulnerability downplayed as a DoS by Linux vendors (as seems to be the norm these days). Oops.

-Brad

The details on loading rootkits via /dev/mem

Posted Apr 28, 2009 14:39 UTC (Tue) by spender (guest, #23067) [Link]

Also, in case it wasn't clear from the previous post, the "much easier way" to solve the problems referred only to this particular scenario we're discussing with /dev/mem. It should be clear that the protection discussed in the paper is useful against kernel exploitation as well and in fact is quite close to the concept of KERNSEAL which the PaX team came up with in 2003. Google reveals a couple results on KERNSEAL, but the PaX team hasn't released a definitive explanation of the implementation, which is likely why it wasn't referenced by the paper you linked to.

-Brad

Checking the attributions ...

Posted Apr 29, 2009 0:01 UTC (Wed) by AnswerGuy (guest, #1256) [Link] (1 responses)

Regarding "to the point where I have to check the author lines to see if it's not secretly one and the same person."

... it's possible that they are secretly one person and that this is a case of deliberate astroturfing.

Personally I would think it would be rather crude and ineffective astroturfing --- I think the better techniques involve inserting criticism which superficially seems "helpful" and constructive while providing snippets that can be taken out of context by the front line "analyst" flaks.

But then ... what would I know?

JimD

Checking the attributions ...

Posted Apr 29, 2009 6:48 UTC (Wed) by nix (subscriber, #2304) [Link]

They're different people in the real world of the internet, outside of
LWN: and of course as you know you can believe everything you see there.

The details on loading rootkits via /dev/mem

Posted Apr 20, 2009 23:08 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

This whole 'make executable memory readonly' _stinks_ of possible race conditions, especially on multiprocessor machines.