@dangoodin on a combo colour cartridge you might have three or even four separate EEPROM blocks for those colours, so maybe 256 bytes if you're lucky. from which you'd have to trigger the exploit, gain code exec on the printer, and somehow pivot that into malware delivery elsewhere (including storage or download of that malware!)
that is a ludicrously tall order, and would still be strongly predicated on multiple severe firmware bugs in the printer.
@gsuberland @dangoodin
Exactly, if the firmware is really badly buggy a microprocessor emulating a EEPROM could do harm. But if it could it would be negliant if HP didn't fix these bugs which they apperently know about.
@freemin7 @dangoodin precisely. that's the crux of the dishonesty in his claim - even if these things did somehow exist, they'd be 100% be HP's fault and could only persist due to HP's negligence.
@gsuberland @dangoodin If i tried i could write firmware so bad that such security holes exist but you really would have to try.
Like how do you get an BufferOverflow from a 256 byte EEPROM? You'll have to have the cartridge control how much data is read which is extra effort to implement. HP would need to be actively building such security holes as with okay software practices they should never occour.
@freemin7 @dangoodin yep. and even if newer stuff is using fancier embedded security tech (e.g. secure element) with more storage, that upgrade inherently raises the bar for building an exploit anyway, and the interaction is still extremely minimal, so there's zero excuse for writing vulnerable code when there's that small of an attack surface area (especially when it's intended to be a security feature, albeit for a shitty goal!)
