Re: Design flaw in Lexar JumpDrive

["Greenarrow 1" <Greenarrow1 () msn com>]

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