Re:Why I won't recommend Signal anymore
by angry_octet on Tuesday November 08, 2016 @09:53PM
(#12905759)
Perhaps I did not isolate my concerns in sufficiently deliberate language.
You may be aware that of late there have been numerous buffer overflows (or other parsing problems) in standard image parsing libraries. Where these are implemented in Java that may be less of a concern, but this type of task is often handled by native code. And while more Java exploits are via breaking the verification in clever ways, via reflection or priviledged calls or pickling, that does not rule out that processing external data can lead to an inconsistent state. It might not be a problem with gifs, if they are small, but animated gifs can be large. Or maybe java
See this discussion on Android image processing:
https://code.facebook.com/posts/366199913563917/introducing-...
The point of PNaCL is that you can use it to sandbox components within the same process/permission set, you don't have to rely on the OS. It has a much smaller attack surface than Java.
You talk about NX and ASLR being useful in the same post as you say buffer overflows can't happen. In any case, while they may be designed to restrict attackers, they are by no means sufficient. There are Java ROP gadget chain builders! JVMs use JIT, which inherently means they are creating new code. Eg. see jit spraying.
You may be aware that of late there have been numerous buffer overflows (or other parsing problems) in standard image parsing libraries. Where these are implemented in Java that may be less of a concern, but this type of task is often handled by native code. And while more Java exploits are via breaking the verification in clever ways, via reflection or priviledged calls or pickling, that does not rule out that processing external data can lead to an inconsistent state. It might not be a problem with gifs, if they are small, but animated gifs can be large. Or maybe java See this discussion on Android image processing: https://code.facebook.com/posts/366199913563917/introducing-...
The point of PNaCL is that you can use it to sandbox components within the same process/permission set, you don't have to rely on the OS. It has a much smaller attack surface than Java.
You talk about NX and ASLR being useful in the same post as you say buffer overflows can't happen. In any case, while they may be designed to restrict attackers, they are by no means sufficient. There are Java ROP gadget chain builders! JVMs use JIT, which inherently means they are creating new code. Eg. see jit spraying.