What are you saying now? Even if you go all in and learn the arcane CLI rituals as the One Holy GNU intended, you are still exposed to security bugs? Are you trying to say that the Holy GNU is a tin god?

The imagery of the Linux haters handbook where neckbeards show their scars as proof of their knowledge and experience is relevant as ever.

I very much wait WannabeFree’s answer to this. Just some days ago he was saying how only stoopid users who use X are exposed to security bugs, and that users a)should learn the CLI and b)would be safe if they used the CLI. If he chooses to come out of his hole of course, because he will most likely try and pretend this never happened, and in a week or so he will emerge again as if this FUD post never happened and start spewing his usual nonsense again.

I like how my argument fell onto deaf ears at this particular instance:

http://tmrepository.com/fudtracker/typical-linux-security/#comment_9397

A charming little read. I’ve taken the liberty of using it on the Pog Blog against his latest rant that Linux “learns from its mistakes.”

Seriously. Who, outside the Linux world, would believe that /proc/pid/mem is actually a good idea?

What possible value does it offer?

Without wishing to dive too far into the technicalities, and admitting that this exploit is beyond my current knowledge, I particularly like this little gem:

“It turns out that su on the vast majority of distros is not compiled with PIE, disabling ASLR for the .text section of the binary!”

So, for this and future exploits, all a black hat has to do is to type:

readelf -h /bin/su | grep Type

and look for non-relocatable .text sections.

Sweet! And such a good advertisement for allowing a bunch of downstream know-nothings to fork around with the stuff.

Love the commit, that introduced this vulnerability http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=198214a7

“With recent changes there is no longer a security hazard with writing to /proc/pid/mem. Remove the #ifdef.”

No longer a security hazard indeed. Touching security related code in front of million eyes and it took them only a year to notice that something is happening.

Note: I’m not counting age of vulnerability from the date when vulnerable code was introduced (it’s stupid – only loons do that), but making fun of many eyes that couldn’t detect bugs like this is perfectly OK.

And blogpost itself is very interesting read. It shows Linux’s take on security: never ever design things – just put some ad-hoc patches over some older ad-hoc patches over some stupidity and hope that noone ever untangle that mess.

I’ve also just noticed that BKL didn’t really go away – it’s just been replaced with BKRCUL (basically always-exclusive mutex was replaced with RW lock) – do they ever learn?

@DrLoser
Here is TLDR version:

1. There is a check to allow you to open your own /proc/self/mem – so just open it, lseek64 it to the required address, redirect (dup2) stderr to it then exec(“su $shellcode”) and voila – su has just overwritten its own memory with your shellcode.

2. B-b-b-b-but there is a special check to prevents JUST THIS:

And when file is created this self_exec_id is copied into its private_data. And when you exec you get new self_exec_id. Sounds about right? Su-u-u-ure, except this self_exec_id is entirely user controllable: you get a copy of your parent’s self_exec_id when you’re forked, you get your self_exec_id incremented when you exec.

So, just fork yourself (get a copy of “id”) – exec to yourself (increment “id” to match one that su will get once parent process exec-s itself), open /proc/parent-PID/mem for writing (private_data gets incremented exec_id) sendmsg/recvmsg handle to the parent… lseek64, dup2, exec(“su $shellcode”), pwned

3. Yeah, and there is another security measure – ASLR, that is supposed to prevent exactly that. Guess what? It’s disable for such an unimportant binary as su

I particularly liked the cunning way they get a security id for one of those steps: take a really, really, bit gaussian field and increment the last value you saw (locally, mind; this isn’t a central function in the kernel) by one.

You would think that, since they have condemned themselves to an insane world of parent/child processes, it might have occurred to them that “the last number you saw” isn’t particularly unique in any way.

I also admired the comment at the bottom: “this is old hat,” complete with a link to 2005. Which I can’t quite retrieve from Wayback at the moment.

But that’s all right, isn’t it? We noticed this glaring defect in 2005. Presumably the #ifdef was even wrapped around it in 2005.

No need to worry seven years later, then.

Use the search engine, search engine guy :-)

http://www.google.com/#q=inurl:wth_the_proc_pid_mem_problem

And here is a nice little screenshot: http://i.imgur.com/ASAww.png

Linux: fighting stupid security issues for 15+ (wanna bet it’s not fixed yet?) years.

I am contractually forbidden from using that one.

That’s a single feature I’m still using ThatOtherSearchEngine™ for. Bing has url: and site: but doesn’t have inurl:

“I am contractually forbidden from using that one.”

Knowing how Microsoft suffers from not invented here (ex MovieMaker still doesn’t support saving as MP4) I will have to ask you if the quote above was really a joke. Or is it for real?

It was a joke (at least somebody around here can spot jokes: do you feel like explaining the process to Kim?).

Actually they encourage us to use google, for obvious reasons.

For each GNU/Linux security bug there are a hundred Winders ones.

@Wants2BFree:

No no, Adam, you are confusing “security bugs” with “users,” as always.

It’s a tricky concept to get your head around, isn’t it? Particularly when you are incapable of quoting any figures to back your claim.

Want2BFree, like the old adage goes, for every rat you see, there are 50 you didn’t see. What this means is with a smaller user base, there are fewer people to test and report bugs. This, in turn, means there are plenty of bugs that fly under the radar.

Guys, I humbly ask for a clarification here.

As far as I know, Windows reserves 64K of address space starting at 00000000 to trap null pointers.

However, again as far as I know, for compatilibity reasons with 16 bit apps, which might reseve memory there, Windows somehow allows them to do so.

How is this achieved, and can it be exploited?

Thanks in advance for enlightening me.

“Windows reserves 64K of address space starting at 00000000 to trap null pointers.”

The address space you are talking about here is virtual, not physical. See:

http://www.tech-archive.net/Archive/WindowsCE/microsoft.public.windowsce.embedded/2005-03/0301.html

“However, again as far as I know, for compatilibity reasons with 16 bit apps, which might reseve memory there, Windows somehow allows them to do so.”

16-bit applications are supported in NT via “thunking”, meaning that their code is simply translated from 16-bit to its 32-bit equivalent before execution. A 16-bit Windows-on-Windows (WoW) session also has its own virtual memory address space.

http://technet.microsoft.com/en-us/library/cc767884.aspx

And the answer to “can it be exploited?” is, as a consequence, “Not really.”

You wouldn’t believe the amount of effort Microsoft put in to making the thunking work from the 16-bit virtual environment (and back). There might be a security hole buried in there somewhere, but it’s ridiculously unlikely.

Consequently, the best you are likely to be able to do is to compromise another 16-bit executable in the virtual environment. Which isn’t much use, because the minute you thunk out of that environment, you’re back to standard Windows 7 security guarantees.

I suppose you might be able to corrupt a file on disk if you tried really, really, hard.

Thanks, guys.

I still don’t get all details. I will do some more reading on how thunking works with pointers.

It isn’t how thunking works with pointers.

It’s how virtual memory works with real memory.

You don’t get a pointer into real memory: you get a pointer into virtual memory, which is part of your personal process space. The mapping from there to real memory is entirely under the control of the OS, which in this case happens to involve thunking, but that’s just a side-issue.

“As far as I know, Windows reserves 64K of address space starting at 00000000 to trap null pointers.”

Not directly. The VirtualAlloc() and WinAPI functions will leave the page untouched. So by default, you can’t use that space.

However, it is possible using NtAllocateVirtualMemory(). With that, you can actually allocate the null page and make usage of it. You shouldn’t, of course, except for special purposes like placing a page guard there to handle null pointer errors specifically. ( EMET for instance can do this to protect legacy apps by terminating them deterministically once a null pointer is hit )

I’m not an ntvdm expert, so my answer is in no way authoritative, but here is something I think needs clarification:

16-bit code is not binary translated into 32-bit, it’s ran natively using http://en.wikipedia.org/wiki/Virtual_8086_mode (and this is the reason x64 Windows doesn’t support ntvdm). Thunking ( http://en.wikipedia.org/wiki/Thunk_(compatibility_mapping) ) is used to translate DOS calls (e.g. int 21h) into native Windows calls (mainly NtVdmControl) and there actually was a vulnerability (CVE-2010-0232), related to memory usage but it was related to differences between protected and v8086 mode selectors (you can’t set 2 least significant bits of selector to whatever you want in protected mode but you can in v8086 and real modes) + some race conditions (pretty tricky bug I must say and Tavis Ormandi actually told that he benefited from NOT BEING ABLE to access source code).

v8086 mode is subject for all OS memory usage restrictions, though there is a check that is made for ntvdm-capable processes to make them able to allocate starting from virtual address 0.

Actually there COULD be a vulnerability if some driver doesn’t check validity of a pointer (and there was a famous Linux bug), but in most cases not being able to allocate NULL doesn’t “fix” such vulnerabilities – just mitigates them (converting from EoP to DoS).

Anyway, it’s good that this has been removed.

Oh noes, we found a security hole in Linux. Let’s ignore the thousands of security holes in Windoze!

Linux is MORE SECURE then Mafia$oft’s crappy garbage OS.

And no, I’ve proven this without a doubt multiple times so don’t even bother arguing with me. If you disagree with irrefutable facts you should probably die in a fire for being so f**king stupid.

@Adam:

“Let’s ignore the thousands of security holes in Windoze!”

What, like calling them out in public? Funny way to ignore them, I would think.

Let us know when a Linux security hole is actually caught by a LinuxSecurityExpert™, rather than Mitre or some random geek who isn’t blinded by the evanescent joys of SELinux.

Security through obscurity isn’t actually security, Adam.

Here, take a look at this:
http://ugcs.net/~keegan/talks/kernel-exploit/talk.pdf

Admire how much the precious linux is secure. While some of the technical details here are hilarious, the more interesting part is as follows: – some bugs in the more obscure parts of the kernel are dragged for years. – the million masturbating monkeys army, pardon me, I meant 'many GNU/eyeballs’ can reintroduce the said bugs. – updating your kernel IS NOT sufficient to keep your kernel secure (page 77). (I’m not saying anything about userland)

What security?

Dr. Loser, I clearly distinguish between virtual and physical memory, and I have in mind the virtual one.

ChristX, Linsuxoid, thanks for the explanations. It is clearer for me now.

Not even deserves a new FUD. State of the Linux security http://packetstormsecurity.org/files/109230/advisory_sudo.txt

Untrusted data as a format string? In The Center Of Linux Security? Seriously? SERIOUSLY?!! How come million eyes didn’t notice this bug in a perfectly linear and straightforward code? How come LinuxSecurityExperts™ made this n00b mistake at all?