61–70 of 94 posts
Earlier quoted context omitted.
All in the name of DRM.
As far as I understand it the AMT is like IPMI. It's for remote management, not DRM.
Earlier quoted context omitted.
IPMI falls into similar waters, and also has known design flaws around authentication. :(
IPMI normally has a dedicated NIC (well, on some crappy boards it doesn't), which tends not to be connected to public networks.
Unfortunately though, too many of them still seem to make the connection. eg looking through Shodan quickly just now still shows potentially 1k+ examples. Ugh. :(
But you're right that it's a lot less than is likely present for this AMT problem.
TL;DR: memcmp(received_passwd_hash, correct_passwd_hash, received_pwd_hs_len) Hey, at least they didn't read past the submitted buffer. edit: Note that this is only pseudocode and rumor has it that ME firmware is actually written mostly in Java. It's not immediately clear to me how to create equivalent bug in Java, the obvious string.equals() method doesn't ignore length mismatch. edit2: s/passwd/passwd_hash to satis…
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…
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)
Earlier quoted context omitted.
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…
> 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 i…
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?
Earlier quoted context omitted.
Intel ME has a DRM app called "Protected Audio-Video Path" [1], which obviously has to be secret. As to whether anything actually uses the PAVP functionality, I have no idea. I wouldn't be surprised if it was something Intel included to try to push Atom-based set top boxes or whatever. [1]: https://www.slideshare.net/mobile/codeblue_jp/igor-skochinsk...
> Intel ME has a DRM app called "Protected Audio-Video Path" [1], which obviously has to be secret. Does it, does it really? I'm pretty sure security through obscurity is some bullshit.
(Needless to say, I'm offering an explanation as to why the Intel ME is what it is, not defending it. I think it's pointless. After all, it's likely that PCs are just not going to get content in the future, given that consumers use set-top boxes that use embedded architectures instead of x86 PCs and Intel has failed in mobile.)
[withdrawn]
Earlier quoted context omitted.
Intel ME has a DRM app called "Protected Audio-Video Path" [1], which obviously has to be secret. As to whether anything actually uses the PAVP functionality, I have no idea. I wouldn't be surprised if it was something Intel included to try to push Atom-based set top boxes or whatever. [1]: https://www.slideshare.net/mobile/codeblue_jp/igor-skochinsk...
Intel ME has a DRM app called "Protected Audio-Video Path", which obviously has to be secret. Which you don't need on a headless server. Which is what the "management engine" is supposed to be for.
Earlier quoted context omitted.
That's a separate system which lives on a daughter board. It's essentially a kvm+usb cdrom+power switch. No disk access, no dma. Not the same thing at all. Edit: and trivially removable if you don't want it.
> No disk access AMT doesn't provide raw disk access either > no dma It's connected to PCI. What makes you so sure that it has no DMA access? > Not the same thing at all Indeed - iLo is pretty good, but the implementations provided by other vendors have an even worse track record than AMT does.
What could possibly go wrong.
Earlier quoted context omitted.
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…
> 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 i…
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.