Link: Twice the bits, twice the trouble: vulnerabilities induced by migrating to 64-bit platforms

November 17, 2016

Adrian Colyer's Twice the bits, twice the trouble: vulnerabilities induced by migrating to 64-bit platforms (via) is a very readable and very interesting summary of an ultimately depressing academic paper on the security vulnerabilities that get induced in C code simply by migrating from 32-bit platforms to 64-bit platforms.

In theory I sort of knew about all of this, but it's one thing to vaguely have heard about it and another thing to see handy comparison charts and examples and so on of how relatively innocent C code introduces real vulnerabilities simply when you rebuild it on 64-bit machines and then expose it to attackers.

Here's a depressing quote from the academic paper to finish up with and motivate reading at least Colyer's summary of the whole thing:

Finally, we make use of this systematization and the experience thus gained to uncover 6 previously unknown vulnerabilities in popular software projects, such as the Linux kernel, Chromium, the Boost C++ Libraries and the compression libraries libarchive and zlibā€”all of which have emerged from the migration from 32-bit to 64-bit platforms.

That's, well, unfortunate. But not unexpected, I suppose. Maybe all future languages should not have any limited-range numeric types that can have different sizes on different platforms, even if it's theoretically an attractive idea for 'optimization'.

(I don't know what Rust does here, but Go does have int and uint, which are either 32 or 64 bits depending on the platform.)


Comments on this page:

By Christopher Barts at 2016-11-18 23:20:02:

Yeah, we could likely have more languages with size-guaranteed types now, but that's because 32 bits and 64 bits are honestly big enough to do most integer-y type things with. Even the smallest, a signed 32-bit integer, is still good for over two billion numbers before you have to deal with wraparound, and unsigned 64-bit ints are bigger than most applications will ever truly need.

However, freezing on a 16-bit integral type would have been massively annoying. Even unsigned 16-bit values are simply too small to give unique numbers to really large numbers of things; look up why the Unix time(2) syscall takes a pointer as its argument, instead of just returning an integral value. Freeze on a type that small, and you get work-arounds which are more failure-prone than what you're trying to prevent.

And if you go back far enough, you'll get to times when freezing on 18-bit and 36-bit sizes might have seemed like a good plan...

By cks at 2016-11-18 23:56:20:

My assumption is that someday we'll add things like int128 and so on. The important idea is that the size of any particular type is fixed for all time when it's created and is guaranteed to never change later. We can always add more types over time, just as we have so far.

(As a practical example, Go has a full set of signed and unsigned integer types in 8, 16, 32, and 64 bits, all specified as being exactly that size. If you write code using uint16, you know exactly what you're getting regardless of what Go does in the future. It's possible that someday your uint16 code will have unfortunate performance implications, but that's another problem; the compiler and language specification guarantee that it still works.)

Freezing odd sized types is a potential problem. My current view is that that's what deprecating language features is for in the long run (and even before then the code is likely to perform increasingly badly because things have to be emulated, which encourages updating it).

By Greg A. Woods at 2016-11-20 18:04:26:

People started chanting "Not all the world's a VAX" practically the day the first VAX went into production.

I continued fixing 64-bit bugs in code that had already been ported to DEC Alpha and SPARC64 platforms back in 2005 or earlier, and of course I went on to port even more code to such platforms back then as well.

It's very sad to see a paper written newly this year documenting continuing problems with such code migration, but even more sad is that it is not unexpected to see such a recent paper on this topic.

Written on 17 November 2016.
« The somewhat odd subject of Django versus Python
Unix shells and the problem of too-smart autocompletion »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu Nov 17 14:01:52 2016
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.