> [...] how to create equivalent bug in Java, the obvious string.equals() method [...]

Java Card, the Java version made for smart cards, does not have strings, and thus no String.equals().

Thought I remembered this from a CCC conference about EMV chips or SIM cards (don't remember which) a few years ago. Googling seems to confirm it: https://community.oracle.com/thread/1751610?db=5

From what I remember in one of the deep teardowns it's possibly Java ME (which I think is one step above Java Card in terms of features). The file format is JEFF.

No. That was another vulnerability used as an example.

In this case, if you don't send some hash, it will authenticate you, allowing you to authenticate with user `admin` and no password.

The article discusses an actual partial prefix match.

> we tested out a case in which only a portion of the correct response hash is sent to the AMT web server. To our surprise, authentication succeeded!

> Next, we reduced the response hash to one hex digit and authentication still worked.

This doesn't imply that "no password" - an empty password would still result in a non-empty HTTP Authorization Digest response hash, which would not allow you to login. An empty/truncated digest response hash is not the same thing as an empty/truncated password.

Quite a bit of Java memory safety comes from the JVM. Array bounds checking, for example. If they're embedding an entire oracle JVM then it's probably pretty safe. On the other hand, if they're compiling down to a home made vm with a home made compiler, well. who knows? Dalvik did that and it had some problems.

It seems really hard to test from the point of an outside observer. I'd strongly suspect it's hard to test internally as well, which would indicate there are a bunch of bugs lurking in there.

> If they're embedding an entire oracle JVM then it's probably pretty safe.

This sounds a bit strange to me. Oracle releases a lot of updates for the JRE.

eg Java 8 is up to number 131 at the time of writing this, though they're probably (hopefully!) not all security updates:

• http://www.oracle.com/technetwork/java/javase/downloads/inde...

• http://www.oracle.com/technetwork/java/javase/8u-relnotes-22...

With that in mind, wouldn't an embedded Oracle JVM be a very bad idea from a security standpoint? (if network connected, and not updated of course)

Oracle JVM is a huge and complicated beast, it's a ridiculous thing to embed in a chip. On the other hand, it's thoroughly tested, and security vulnerabilities are (generally?) fixed in a timely fashion.

A home made, completely un audit able, built in JVM (that apparently can't be updated based on your comments) seems crazy dangerous.

Just saying "it's probably ok, because it's java" as the op alluded to is a very dangerous line of thinking. that only works with one of the public, auditable implementations.

I dunno. it's a the devil you know vs the devil you don't problem. How do you feel about the security of intel software in general?

To put this another way, JVM as a conceptual processor is pretty solid and I doubt there are many massive errors in the design. Your homebrew JVM implementation certainly may contain errors, and the software built on any JVM almost certainly does.

Probably not? Most of the "insecure Java" bugs you hear about are due to exploiting the runtime loader by feeding it fun binaries (jars or whatever). The rest of the problems are things that can occur in any framework and Java is probably safer due to being a memory safe language. The exceptions are when they do things unsafe for speed, like font/image processing, but again, that can happen in any lib.

I'd be surprised to hear that using a Java, say, socket or HTTP lib, exposed you to more risk in general than using any other language/runtime/lib.