3 ms·

In addition to timing attacks, if the attacker supplied a non null terminated string, it could potentially cause a memory overrun. This may not be possible depe

In addition to timing attacks, if the attacker supplied a non null terminated string, it could potentially cause a memory overrun. This may not be possible depending on how the string is handled on ingress, but if it is, it would likely have serious consequences.

qb45 9y ago
The attacker supplies ""-enclosed string and the HTTP parser is supposed to verify this. Maybe they used some in-place HTTP parser and that's why they didn't have zero-termination to use strcmp. And btw, it's not clear if the code was C to begin with. I believe large chunk of ME firmware is said to be written in Java, which kinda makes sense for a network facing system considering how shitty string.h is. It would be interesting if somebody found that they are using some COTS webserver, C/Java - doesn't matter, and see if there are some CVEs for it.
- benchaney 9y ago
  I doubt using Java would really help in this case, because in order to use Java they would have to port the entire JVM to whatever platform they are using. Doing this without introducing any security bugs is about as difficult as just doing everything in C to begin with. By the way, the fact that the issue was with strncmp very strongly suggests that the issue was in C code.
  - dom0 9y ago
    Some security paper showed ARM disassembly of the issue, although I'm not sure if that was this specific issue or just another "strncmp-induced" issue. (Btw. there are many smaller Java VMs for stuff like Java Card and JEFF)
  - qb45 9y ago
    They use ARC architecture and some embedded JVM. Of course this doesn't guarantee that the AMT web server runs on this JVM. Few years ago somebody published analysis of the ME firmware for servers (desktop version was compressed with unknown algorithm). I'm sure you can google this for details. > the fact that the issue was with strncmp But we don't know for sure if it was strncmp. It's a logic bug, which can be implemented in any language. But again, maybe this server runs outside JVM and is written in C.

qb45 9y ago

The attacker supplies ""-enclosed string and the HTTP parser is supposed to verify this. Maybe they used some in-place HTTP parser and that's why they didn't have zero-termination to use strcmp. And btw, it's not clear if the code was C to begin with. I believe large chunk of ME firmware is said to be written in Java, which kinda makes sense for a network facing system considering how shitty string.h is. It would be interesting if somebody found that they are using some COTS webserver, C/Java - doesn't matter, and see if there are some CVEs for it.

benchaney 9y ago
I doubt using Java would really help in this case, because in order to use Java they would have to port the entire JVM to whatever platform they are using. Doing this without introducing any security bugs is about as difficult as just doing everything in C to begin with. By the way, the fact that the issue was with strncmp very strongly suggests that the issue was in C code.
- dom0 9y ago
  Some security paper showed ARM disassembly of the issue, although I'm not sure if that was this specific issue or just another "strncmp-induced" issue. (Btw. there are many smaller Java VMs for stuff like Java Card and JEFF)
- qb45 9y ago
  They use ARC architecture and some embedded JVM. Of course this doesn't guarantee that the AMT web server runs on this JVM. Few years ago somebody published analysis of the ME firmware for servers (desktop version was compressed with unknown algorithm). I'm sure you can google this for details. > the fact that the issue was with strncmp But we don't know for sure if it was strncmp. It's a logic bug, which can be implemented in any language. But again, maybe this server runs outside JVM and is written in C.