LWN: Comments on "vmsplice(): the making of a local root exploit"

QA?

barrygould — Thu, 24 Dec 2009 22:07:48 +0000

ISTM that someone should have tested the exploit against the 'fixed' kernel before declaring it fixed. (more QA is needed in the kernel development processes.)

vmsplice(): the making of a local root exploit

dibbles_you — Sun, 11 Jan 2009 04:06:48 +0000

cd /to/linux/kernel
# find . -name "*.c" | xargs grep ">>" | awk -F ">>" '{ for(n=2;n<=NF;n++) { $c=$n; sub(/^=/,"",$c); sub(/ /,"",$c); gsub(/$/,"",$c); gsub(/$/,"",$c); $c=substr($c,1,1); if ($c>='0' && $c<='9') print "number"; else print "text"; } }' > a
# cat a| grep text | wc -l
# cat a| grep number | wc -l

number=19877
text=4936

so it would seem the linux kernel believes numbers are usually clearer for others to read and understand.

if you believe otherwise submit a patch to the kernel removing all occurrences and replacing them with meaningful #defines.

#define 'ing all numbers is stupid, using identifiers that describe what they are should allow anybody to understand their context, if you use lots of operators and numbers in a single expression split them up to use multiple variables with appropriate names, if they are in conditions use multiple conditions with comments if necessary. The compiler will optimize all these away and make your code more readable without have 15 editors open or using code navigators to work out that the actual value of CLUSTERS_DIVIDE_BY_BYTES_IN_SECTORS_MULTIPLIED_BY_PI(x) is 2.

PS. the script is an approximation.

Bigger caches ? Where ?

phip — Sun, 09 Mar 2008 23:16:27 +0000

> There will never be "bigger cache sizes". Never.

You should check out PA-RISC.  They have L1 D-caches up to 2048K.

Trapping on overflow

anton — Thu, 28 Feb 2008 21:23:14 +0000

Apart from asm statements and modifying gcc I don't know of a way to get gcc or other compilers to use the trapping instructions for C code.

Concerning "no arithmetic in here is supposed to wrap around", unsigned arithmetic is supposed to wrap around in standard C, only signed arithmetic is allowed to trap (or do anything else) on overflow.

It's far from complete

fbh — Mon, 25 Feb 2008 09:02:12 +0000

Acutally you're right.

It's a trick to compute the addresses of the fake "struct page" structures on both 32 and 64
bits platforms.

It should work on 64 bits platforms. I don't know why it doesn't in your case though but it's
just a matter of tuning some values in the exploit code probably.

Thanks.

It's far from complete

cras — Mon, 25 Feb 2008 00:19:41 +0000

I don't know if the exploit was supposed to work as a 64bit binary (I crashed my machine when 
testing one version of it), but that code doesn't translate to "NULL" on 64bit systems.

It's far from complete

fbh — Sun, 24 Feb 2008 10:55:42 +0000

Hello,

I'm suprised to see how this article is far from complete. It misses some important details
and it doesn't actually explain how the exploit works...

For example, the interesting buffer overflow (which is actually not done by get_user_pages()
BTW), is not used to put a return address on the stack at all ! Hint: it's actually used to
put 0 and 0x1000.

And, surprise surprise, the exploit also 'mmap' 2 areas starting by 0 and 0x1000. And these
areas are made up to look like a struct page structure for a compound page where the
destructor field is set to kernel_code() address.

One thing I still miss is why the exploit code is so weirdly written ?
For example, it does:

        pages[0] = *(void **) &(int[2]){0,PAGE_SIZE};

whereas it could have done instead:

        pages[0] = NULL;

Is it something common for exploit code to be ofuscated ?

Trapping on overflow

giraffedata — Sat, 23 Feb 2008 22:24:11 +0000

MIPS and Alpha have separate arithmetic instructions that trap on signed overflow ...

Nice. Do you know if there is any way to make GCC (or any other C compiler) generate such instructions?

I can understand people resisting adding instructions to handle overflow, but if I could declare in my C program "no arithmetic in here is supposed to wrap around" and get signalled to death if it does, I'd do it a lot.

for the record

gvy — Sat, 23 Feb 2008 22:06:18 +0000

* Sun Feb 10 2008 Sergey Vlasov <vsu@altlinux> 2.6.18-alt12
- Security-related changes:
  + CVE-2008-0600: splice: fix user pointer access in get_iovec_page_array()
  + check iovec buffers in __bio_map_user_iov() (fixes issue with SG_IO)
  + guard against attempts to call get_user_pages() for 0 pages

Trapping on overflow

anton — Sat, 23 Feb 2008 21:45:21 +0000

But I don't get why no CPU today provides even the option of trapping on an arithmetic overflow.

MIPS and Alpha have separate arithmetic instructions that trap on signed overflow (e.g., ADD on MIPS and ADDV on Alpha). IA-32 has INTO which traps if OF is set. Apparently this instruction was so rarely used by programmers, that AMD64 removed it in order to free up some opcode space, and did not even bother to allocate another (multi-byte) opcode for it; but you can still implement the functionality by combining JO (or JNO) with INT.

The existence of INTO has not helped against this security hole, though.

Power 6 clock high-score and real performance

anton — Sat, 23 Feb 2008 17:14:18 +0000

It'd be interesting to have a study which analyse whether going in order for integer processing to increase the clock really did improve performance

Take a look at SPEC CPU 2006 results. Last I looked, a 4.7GHz Power6 had similar speed to a 3GHz Core 2 Duo 6850 in both SPECint2006 and SPECfp2006 results.

Bigger caches ? Where ?

renox — Thu, 21 Feb 2008 09:53:51 +0000

>Look at the IBM Power6 for some high-clock cores...

Except that apparently they had a lot of difficulty ramping up the clock..
Plus their CPU does *in order* integer processing which induce a loss of efficiency..

It'd be interesting to have a study which analyse whether going in order for integer
processing to increase the clock really did improve performance or if it was just a marketing
gimmick a la P4.

Bigger caches ? Where ?

renox — Thu, 21 Feb 2008 09:46:47 +0000

>This is place where Linus misses the point completely: there are no "bigger cache sizes".
There will never be "bigger cache sizes". Never. Pentium had 16 KiB L1 

Funny how you restrict the meaning of 'bigger cache size' to 'L1 cache size' to "make your
point".

Sure L1 won't grow, but L2 and L3 cache are also cache you know?

OT: reply

intgr — Tue, 19 Feb 2008 08:09:52 +0000

So it turns out that this indeed is the problem; the stylesheet file sizes only differ in one byte so I didn't catch the difference the first time (I thought they were equal).

--- lwn_logged_out.css  2008-02-19 09:58:38.000000000 +0200
+++ lwn_logged_in.css   2008-02-19 09:57:04.000000000 +0200
@@ -135,7 +135,7 @@
 DIV.CommentBody { padding: 0px 4px 0px 4px; }
 P.CommentPoster { margin-top: 0px; }

-div.CommentReplyButton { display: none;
+div.CommentReplyButton { display: block;
                         text-align: right;
                         padding: 4px; }

The problem here is browser cache. When the user first visits LWN.net, not having logged in yet, the browser downloads /CSS/lwn which specifies that div.CommentReplyButton should be hidden.

Later when the user does log in, the browser doesn't bother re-fetching the stylesheet because it already has this URL cached. The Right Way to fix this is to have different stylesheet URLs depending on whether the user is logged in -- rather than using magic stylesheets.

This code is there not for performance

giraffedata — Sun, 17 Feb 2008 19:50:25 +0000

It is unfortunate that the CPU cannot enforce signedness and size types.

The unfortunateness is at a lower level than that. It's unfortunate that a CPU can't do ordinary integer math, where 2 + 2 = 4. I understand why the very first CPUs wrapped around integers -- it happens naturally with the simplest implementations. But I don't get why no CPU today provides even the option of trapping on an arithmetic overflow instead of wrapping around silently. They do it for floating point, but not for integers.

vmsplice(): the making of a local root exploit

bronson — Sat, 16 Feb 2008 17:13:43 +0000

I guess we will disagree.  Your way is still hostile to new maintainers because it carries so
much implicit information.  What if your code code has this?

   inode->i_blocks = bytes >> 8;

What is a new maintainer to think?  Even if he does recognize that this expression is
different from the others, he's still confused.  Did you auto-optimize the expression (bytes
>> 9)*2?  Is it typoed or a thinko?

Will every potentially confusing use of the shift operator in your code include a comment
stating the author's intention?  If so, then will that convention still be true once someone
else has modified your code?

Also, you've given yourself a rather heavy restriction on variable naming haven't you?  Will
all your variable names really contain "blocks" and "bytes" as appropriate?  You'll probably
want to add this restriction as a comment to each file to which it applies or it won't last
long once other people start committing patches to your code!

Finally, your technique only works for trivial expressions like assignment.  What happens if
you need to actually perform a calculation?

A BYTES_TO_BLOCKS macro solves all these problems by making the conversion explicit.  Implicit
rules and unwritten conventions always make life hard for new maintainers.  Always.

This code is there not for performance

ernest — Sat, 16 Feb 2008 11:28:07 +0000

It is unfortunate that the CPU cannot enforce signedness and size types. 
Anybody programming in assembly can bypass any higher level language type 
checks you have in mind. This is true even if the users has the best 
intentions.

Ernest.

vmsplice(): the making of a local root exploit

dododge — Sat, 16 Feb 2008 01:52:04 +0000

> Consider:
>   inode->i_blocks = bytes >> 9;
> vs:
>   inode->i_blocks = BYTES_TO_BLOCKS(bytes);

It's a bit of an unfair example, though, because you're computing
against a value called "bytes" and assigning it to something called
"blocks".  You've put enough context around the expression to make
it clear what the shift is trying to accomplish.

The problem is when someone assumes ">> 9" is inherently
self-documenting and throws it into the middle of a much more
complex statement.  Consider:

  process_frag_2(sig,(get_ent(curr) >> 9) + 2,HEX_ENCODE);
vs:
  process_frag_2(sig,BYTES_TO_BLOCKS(get_ent(curr)) + 2,HEX_ENCODE);

When I'm reading code, I'd much rather see the latter.  It doesn't
just tell me why the shift is being done; it even adds useful
information about the APIs for get_ent() and process_frag_2().

code obfuscation

man_ls — Sat, 16 Feb 2008 01:21:21 +0000

True. Any idiot can obfuscate his or her code, but it takes work and wit to make legible code.

Magic exists by necessity alone

vonbrand — Fri, 15 Feb 2008 23:23:40 +0000

Even if a "perfect architecture" existed such that "real machines" are "perfect subsets" (real architectures are very different, sometimes in very weird ways), one of the problems writing a kernel is that real hardware is as buggy (or more!) as the next software (in the end, it is algorithms implemented in silicon, with the added burden that bugs can rarely patched and the rebuilt package distributed to the users).

Halting problem ? Ha!

nix — Fri, 15 Feb 2008 21:48:10 +0000

I used the wrong terms, really. What Haskell, Cayenne and Qi provide over 
C++ is (radically) greater *expressiveness*. The syntax of Qi type 
definitions is especially strange, but it's a hell of a lot saner than 
trying to define anything complicated using C++ templates.

OT: reply

madscientist — Fri, 15 Feb 2008 15:07:36 +0000

I see this happen somewhat often using FireFox too.  As you say, the buttons are ALL missing,
and a reload takes care of it.  I checked the source once on these but it looked fine: the CSS
for the buttons was all there.  They just didn't show up.

I've also had situations where the front page says there are replies, but when I click the
link I don't see any replies.  Then if I reload, the replies appear!  This happens more
rarely, but it's happened more than once.

At first I thought it was because I was using the greasemonkey add-on to distinguish between
read and unread comments, but I've since turned that off and I still see both of these
problems.

vmsplice(): the making of a local root exploit

jimparis — Fri, 15 Feb 2008 07:43:24 +0000

> I venture that if you can't see that, you must still be in your
> first job and haven't yet had the task to maintain somebody else's code.

And I venture that, in my experience (which is not as limited as you impolitely presume),
"somebody else's code" is a whole lot more difficult to work with when I have to dig through
arbitrary levels of opaque macros to figure out what they're really trying to do.

Clearly we have a difference in opinion.  I prefer in code that is written clearly enough to
be self-explanatory.  Consider:
  inode->i_blocks = bytes >> 9;
vs:
  inode->i_blocks = BYTES_TO_BLOCKS(bytes);

If you maintain that the second version conveys more information than the first, then I'm
afraid we will just have to disagree.

vmsplice(): the making of a local root exploit

JoeF — Fri, 15 Feb 2008 06:54:55 +0000

Using ">> 9" is essentially a comment saying "I'm converting this to a 512-byte sector count".

No. It only says that you shift a value by 9 bits to the right.
It may say to you that you are converting a value to a 512-byte sector count. It does not necessarily say that to others.

It's such a fundamentally basic operation that anyone working with filesystem or disk code would understand it immediately.

That mindset is what results in a lot of the flaws in all kinds of code. There will always be somebody working on the code for whom it isn't obvious. I venture that if you can't see that, you must still be in your first job and haven't yet had the task to maintain somebody else's code. I can tell you from (painful) experience that this kind of stuff is among the worst stuff out there.
">>9" makes implicit assumptions, and implicit assumptions, even if they may seem reasonable to the original author, are often not obvious to maintainers, possibly years down the road.
Oh, and just in case, I am writing filesystem code. I would never even get the idea to write something like ">>9" without a comment, or better, in a macro.

Halting problem ? Ha!

ms — Fri, 15 Feb 2008 00:06:49 +0000

No, nix wasn't joking. If you use C++ templates and limit yourself to numbers then it really
is turing complete. Haskell, with the right flags (undecidable instances and overlapping
instances) is also Turing complete. Cayenne is deliberately so and many people are now really
thinking that it's just better to permit Turing completeness and let the programmer take
responsibility.

The alternative is more like what Epigram is looking at (amongst others) where you limit
recursion to on the structure of terms and prevent infinite structures. That way, you can
still guarantee termination. I fear we may now be some way from the original issue though ;)

Halting problem ? Ha!

lysse — Thu, 14 Feb 2008 22:01:38 +0000

I don't know if you're joking about C++, but one of the notable things about Qi is that its
type system *is* Turing-complete, by intent and proof (someone implemented SK combinators in
it).

vmsplice(): the making of a local root exploit

jimparis — Thu, 14 Feb 2008 20:42:23 +0000

> You either need to add a comment, or use a define.
bytes >> 9 without a clarifier is something that should never be in production-quality code.
Magic numbers should never be in code without a clear explanation what they mean.  If you don't
want a macro that can hide things, write something like bytes >> SECTOR_SHIFT.

If one doesn't want to hide things, hide it inside "SECTOR_SHIFT"?
I'm sorry, I remain unconvinced.
Using ">> 9" is essentially a comment saying "I'm converting this to a 512-byte sector count".
It's such a fundamentally basic operation that anyone working with filesystem or disk code
would understand it immediately.

Abstracting common constants is most useful when they might change, and they're just arbitrary
to begin with -- HZ for example.  Or things that actually have no real meaning, like magic
numbers that identify a filesystem.  For a number that has a real, well-known meaning, and for
which changing would involve huge logic changes in the code, I think macros like that are just
extra levels of obfuscation.

vmsplice(): the making of a local root exploit

JoeF — Thu, 14 Feb 2008 19:44:23 +0000

You either need to add a comment, or use a define.
bytes >> 9 without a clarifier is something that should never be in production-quality code.
Magic numbers should never be in code without a clear explanation what they mean.
If you don't want a macro that can hide things, write something like bytes >> SECTOR_SHIFT.

One possible SELinux trick

corbet — Thu, 14 Feb 2008 15:06:07 +0000

I just ran across this posting from James Morris on how SELinux (in recent kernels) can block the mapping of memory into very low addresses - a feature which would have defeated this particular exploit.

OT: reply: FireFox versus CSS

hummassa — Thu, 14 Feb 2008 14:42:11 +0000

I think it is a CSS problem. As I use non-standard colors, when I do the same operation ("log
in to read this article"), it comes back with the default colors instead of my colors. At this
point, I refresh the page... hence I don't encounter the "no buttons" problem.

vmsplice(): the making of a local root exploit

corbet — Thu, 14 Feb 2008 13:44:25 +0000

The exploit is able to run arbitrary code in kernel mode, so the answer has to be "no." Unless one had previously configured SELinux to disallow access to vmsplice() altogether, of course.

OT: reply

intgr — Thu, 14 Feb 2008 11:51:28 +0000

I've seen this repeatedly with Firefox, probably because I always throw out all browser
cookies on exit; the refresh trick always fixes it.

This is how the problem occurs for me:

1. I'm not logged in and click on an article that requires subscription; LWN informs me that I
can't see this article.
2. I click on "log in to read this article"; https://lwn.net/login?target=/Articles/268783/
3. After filling in username and password, I'm redirected to the
http://lwn.net/Articles/268783/ page without the "reply to this comment" buttons -- as if LWN
thought I wasn't logged in.
4. Reloading the page makes the buttons appear.

To reproduce the bug again, I have to clear my cache (!) after logging out. This would suggest
that it depends on some external dependency (like CSS or JavaScript) that varies depending on
login, but gets cached pre-login by the browser. However I couldn't find such dependencies on
the LWN site.

vmsplice(): the making of a local root exploit

dale77 — Thu, 14 Feb 2008 08:16:28 +0000

Anyone know whether SELinux would have prevented this exploit?

vmsplice(): the making of a local root exploit

jimparis — Thu, 14 Feb 2008 06:40:51 +0000

> While hardware sectors may be 512 bytes (currently), filesystems usually deal with larger
blocks.

All the more reason to be just specify it clearly at the point of use rather than hiding it
away in a #define!  See my response above too.

vmsplice(): the making of a local root exploit

jimparis — Thu, 14 Feb 2008 06:38:52 +0000

> > For example, if you work on code related to SCSI or filesytems or otherwise connected with
disks, you're expected to recognise that (bytes >> 9) converts from a byte count to a sector
count, since sectors are 512 bytes.

> However, a well-crafted macro BYTES2SECTORS(bytes) would give me a clue, and the magic
numbers and operations on them would live in the definition of the macro, so you've got one
place to maintain the conversion and it's clear to us noobs what it's related to.

But in the context of the kernel, hiding things in a BYTES2SECTORS macro can be downright
dangerous.  What types does it handle for input and output?  Does it sleep or have any locking
requirements?  If I pass an expression, do I have to worry about side effects if it gets
evaluated twice?  How does it behave if bytes is not a multiple of one sector?
Is it talking about the canonical 512-byte defintion of a sector or the actual 2048 byte
sectors used on CD-ROMs?

"bytes >> 9" is absolutely clear.  I see instantly that it handles integer types and matches
the signedness.  It is free from side effects and fast.  I know that the answer is rounded
down to the nearest whole sector.  Sectors are 512 bytes.

I don't see why you would want to hide all of that information from a developer.  Your version
is only simpler at a quick glance to a casual observer, not someone who actually has to deal
with the code and what the statement actually does.

vmsplice(): the making of a local root exploit

hmh — Wed, 13 Feb 2008 20:32:55 +0000

Apparently, there is a lot more technical details to this exploit.

See http://article.gmane.org/gmane.linux.kernel/639206 for some very interesting info from an
anonymous source in .hu.

Bigger caches ? Where ?

hmh — Wed, 13 Feb 2008 20:23:58 +0000

In mainstream consumer CPUs, maybe the clocks have stabilized (which IS a good thing, we
already waste too much power just to do office work).

Look at the IBM Power6 for some high-clock cores...

vmsplice(): the making of a local root exploit

dw — Wed, 13 Feb 2008 18:03:25 +0000

As a matter of diligence I (like many, many people) document large swathes of my code in the
form of comments. Basically anywhere it has taken me more than a moment to think about, or
where the purpose of the code cannot be inferred by reading API documentation for the calls
made inside it.

Magical integer literals and bitshifts fall well within this purview, and I cannot see it as
"noobness" in these two specific cases. Imagine someone had to go back and fix all those
bitshifts when we move to Some New Compiler (in Some Hypothetical Future). Can't be regexed,
no central place where a change can ripple through the tree, and utterly dangerous, say, if
this New Compiler takes advantage of the fact that bitwise right shift on a signed number is
undefined according to ANSI C (I'm taking this as one, single example. There are hundreds
more).

I understand that other peoples' code is difficult to comprehend. Hell, I've read more than my
fair worth of Other Peoples' Code. I'm talking specifically about why the Linux kernel seems
to be so full of this, but other commenters have given good reasons for some of this already.

vmsplice(): the making of a local root exploit

landley — Wed, 13 Feb 2008 17:34:21 +0000

So code other people wrote is harder for you to read than code you wrote.  
Join the club.  For code you wrote, you'd better have a complete 
theoretical model in your head or it won't work.  For other people's code, 
you're trying to reverse engineer their thought process by taking apart a 
machine they built.

So if you haven't figured out yet that source code is inherently harder to 
read than it is to wrote, or that working code accumulates complexity as 
it has to deal with a real world that does not cleanly match simple 
theoretical models, you're definitely on the "newb" side rather than 
the "professional" side.

Read this:
http://www.joelonsoftware.com/articles/fog0000000053.html

And note how much else out there agrees with it:
http://www.spinellis.gr/codereading/
http://withoutane.com/rants/2007/when-you-read-code
http://blogs.msdn.com/oldnewthing/archive/2007/04/06/2036...

and so on...

vmsplice(): the making of a local root exploit

landley — Wed, 13 Feb 2008 17:09:06 +0000

It's easier for you to read what you wrote than it is for you to read what 
someone else wrote, therefore the problem is with the other person?

Reading code is always harder than writing code.  When you write code, by 
definition you have a working model of the code in your head and 
understand all the concepts involved (or it won't work).  When you read 
someone else's code, even well commented source code, you're trying to 
reverse engineer their thought process based on a machine they built which 
was primarily designed to function, not to teach.

Beyond that, working code is often complicated because it has to deal with 
the real world rather than a theoretical model.

Go read this:
http://www.joelonsoftware.com/articles/fog0000000069.html