This is another example of corporate greed over security of the hardware/software. I cannot imagine there was no research and development for this device. I have tried to find the papers on the development but to no avail. Anyone having knowledge of the planned development of this please post a link. I buy Lexar products so I am concerned about this as if one product is flawed what about others?
The advisory states that notification will be provided. Does this mean a fix is posted or just a scheduled for repair? Does anyone feel Stake's response was appropriate, ie, "users of the device should not trust security, etc"? What about a fix as I am quite sure a patch can be accomplished to fix this flaw? Are they avoiding an outright problem by making excuses as it seems they avoided this issue by not responding to a priority flaw. Does anyone notice a trend in companies responding to flaws as above? Regards, George Greenarrow1 InNetInvestigations-Forensics - ----- Original Message ----- From: "Kenneth R. van Wyk" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, September 28, 2004 11:01 AM Subject: [SC-L] Design flaw in Lexar JumpDrive > Greetings SC-L folks. Wow, it's been absurdly quiet here lately, and not > just > because I've been out of the office on travel so much. Perhaps we've > reached > an end of Software Security topics to discuss? ;-) > > In any case, I thought that I'd try to seed things a bit with this... > > I know that this isn't exactly _news_, as it's a couple weeks old now, but > it's interesting nonetheless. A recent @Stake advisory > (http://www.atstake.com/research/advisories/2004/a091304-1.txt) detailed a > vulnerability in Lexar's JumpDrive USB drive. > > According to the @Stake advisory, even though the device is able to > encrypt > user data using 256-bit AES encryption, "The password can be observed in > memory or read directly from the device, without evidence of tampering." > That strikes me as a pretty glaring example of a _really bad mistake_ made > in > designing the crypto system. > > Certainly not the first -- or, I'm sure the last -- time that we've seen > mistakes like this. It seems to me, though, that a good threat modeling > exercise should have prevented this from being introduced into the product > in > the first place. Or, do you think that the developers knew of the > problem, > but the pressures of product marketing overwhelmed sound design practices? > It's a rhetorical question, obviously, since I can't imagine anyone from > the > design team speaking up publicly, but it sure would be interesting to > know... > > Cheers, > > Ken van Wyk > -- > KRvW Associates, LLC > http://www.KRvW.com
