
Vulnerabilities induced by migrating to 64-bit platforms - ingve
https://blog.acolyer.org/2016/11/17/twice-the-bits-twice-the-trouble-vulnerabilities-induced-by-migrating-to-64-bit-platforms/
======
mcherm
Worth noting: while taking code written for 32-bits and migrating it to a
64-bit environment can accidentally introduce new vulnerabilities, it is ALSO
possible for the opposite to happen. That is, you can take code written for a
32-bit environment and compile it for a 64-bit environment thus FIXING some
vulnerabilities: probably ones you didn't even know about. Given how common
buffer-overrun vulnerabilities are in 32-bit code, I wouldn't even be
surprised if it is more common to increase safety than decrease it.

~~~
static_noise
Supporting multiple platforms also has the benefit that broken code more often
results in observable bugs.

------
woliveirajr
> Many software vulnerabilities are rooted in subtleties of correctly
> processing integers, in particular, if these integers determine the size of
> memory buffers or locations in memory.

So, proper care of buffer overflow doesn't end when test everywhere if you're
really within bounds, but when conversions from different sizes of data types,
given that 64 and 32-bits number types can use more or less bytes in memory.

And in one of the examples:

> For example, assigning a pointer to an int variable under ILP32 is never
> truncating (4 -> 4), but on the 64-bit platforms it is (8 -> 4).

------
cesarb
This shows the wisdom of requiring explicit casts for truncating conversions,
as found for instance in Rust.

------
Kenji
This is why you should use stdint.h as much as possible, then you know exactly
what kind of integers you're dealing with.

~~~
AnimalMuppet
Yes, but that doesn't tell you how big pointers are. One of the big problems
comes with assigning a pointer (which is 32 bits) to an integer and back. You
can specify that it's a uint32, but that doesn't save you - when pointers go
to 64 bits, it still doesn't fit.

~~~
chrisballinger
What about uintptr_t?

~~~
AnimalMuppet
Yes, absolutely. If you're trying to put a pointer into an int-ish variable,
that's what you should be doing - _not_ any of the int types that have a fixed
number of bits.

------
tptacek
This is good work, but unless I'm missing something, it's not news. For a
public example, Georgi Guninski had a qmail vulnerability --- one of the only
ones --- over a decade ago, and it was an LP64 integer bug.

~~~
Cyph0n
The contribution is surveying and describing the vulnerability in a formal
manner. A paper doesn't always need to contain "news".

~~~
tptacek
Of course! It's less a criticism of the paper than a note that the tone of the
post summarizing it is a little misleading.

~~~
Cyph0n
That makes sense.

------
hannob
The recent libotr vulnerability is a good example of such a bug that appeared
with 64 bit:

[https://www.x41-dsec.de/lab/advisories/x41-2016-001-libotr/](https://www.x41-dsec.de/lab/advisories/x41-2016-001-libotr/)

