3 ms·

Plus the complaint about giphy seems to completely miss the point that the more 'random messaging users' Signal attracts the better from a POV of deniability/et

by mst 10y ago

Plus the complaint about giphy seems to completely miss the point that the more 'random messaging users' Signal attracts the better from a POV of deniability/etc.

angry_octet 10y ago
Although the masking effect may be useful, my immediate thought was how much extra code and buffer overflows had been added to the client. Android doesn't have any sandbox mechanism like pnacl to contain such code.
- moxie 10y ago
  The code in question is written in Java, so the type of memory corruption vulnerabilities you're thinking about are not a possibility: https://github.com/WhisperSystems/Signal-Android/tree/master/src/org/thoughtcrime/securesms/giph https://github.com/WhisperSystems/Signal-Android/tree/master...
- md_ 10y ago
  In addition to Moxie's comment about using Java, you're more broadly confused, I think. Pnacl provides sandboxing, but it doesn't seem to provide any protection against buffer overflows. Android apps are also sandboxed, so I'm not sure what your point was. Android (at least recent versions) has both NX pages and ASLR, both of which are specifically designed for these kinds of attacks. Sandboxing isn't, really, especially if your sensitive content (messages!) are inside the sandbox, obviously.
  - angry_octet 10y ago
    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-fresco-a-new-image-library-for-android/ 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.

by mst 10y ago

Plus the complaint about giphy seems to completely miss the point that the more 'random messaging users' Signal attracts the better from a POV of deniability/etc.

angry_octet 10y ago

Although the masking effect may be useful, my immediate thought was how much extra code and buffer overflows had been added to the client. Android doesn't have any sandbox mechanism like pnacl to contain such code.

moxie 10y ago
The code in question is written in Java, so the type of memory corruption vulnerabilities you're thinking about are not a possibility: https://github.com/WhisperSystems/Signal-Android/tree/master/src/org/thoughtcrime/securesms/giph https://github.com/WhisperSystems/Signal-Android/tree/master...
md_ 10y ago
In addition to Moxie's comment about using Java, you're more broadly confused, I think. Pnacl provides sandboxing, but it doesn't seem to provide any protection against buffer overflows. Android apps are also sandboxed, so I'm not sure what your point was. Android (at least recent versions) has both NX pages and ASLR, both of which are specifically designed for these kinds of attacks. Sandboxing isn't, really, especially if your sensitive content (messages!) are inside the sandbox, obviously.
- angry_octet 10y ago
  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-fresco-a-new-image-library-for-android/ 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.