lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
From: l8km7gr02 at sneakemail.com (l8km7gr02@...akemail.com)
Subject: AW: 9/11 virus

 >Tom Vogt:
 >
> It ain't a user-dependent vulnerability. It exploits shortcomings in the
> interface. It exploits the fact that what the machine does is not what the
> user wants or expects it to do.
> 
> User: 
> "I want to see this picture."
> 
> Machine: 
> Ok...
> ...oh, it isn't a picture, it's an executable...
> ...so, let's execute it.

Hi Tom.

On this point, you and I agree -- a user should never receive
indication from the UI that an executable is a picture, and then
surprise the user by executing something which wasn't really a picture
after all.  Implementing a UI which uses an arbitrary file naming
convention to indicate the executability of a file, /and then going
ahead and hiding the file extension by default/, is unbelievably
braindead.  It's like they *tried* to blur the line between program and
content.  Hmm.

> The user never wanted to execute a file, he wanted to see a picture. It's a
> miscommunication issue, not stupidity of users. A better interface would
> prevent it. For example, imagine for one second that there were no implicit
> actions, i.e. there is no "doubleclick and the right thing will happen", but
> you always have to state WHAT you want to do.(*)
 >
 > ...
 >
 > (*) And don't tell me users wouldn't accept that. Every other
 > electronic device works that way. You don't press POWER on your TV and
 > expect it to know which channel you want.

I maintain, though, that there is a lack of user comprehension involved
(you said 'stupidity', not me) -- a user needs to know what an
executable is, before they can understand there's a certain amount of
danger involved with clicking on them.

As to your suggestion that the implicit behaviour of a doubleclick is a
problem, I think you're a bit off the mark.  Users know that a
doubleclick will 'Open' whatever they click on, there's no ambiguity
there.  The confusion only occurs when the user doesn't exactly know
what it is they're doubleclicking on.

> It's not a user issue. Users aren't stupid, they just have a limited need to
> know. You'd be shouting at your car mechanic if he told you that it's your
> fault that the car burst into flames because that's just what it does when
> you open the trunk while the headlights are on and the gear is in reverse.

I think a (slightly) more appropriate analogy would be a mechanic who
explains time and time again that one should *never* put fuel into a car
unless they know for certain it's unleaded and from a 'safe' source (and
actually fuel and not peanut butter!)

I think we agree on the main points, but have slightly differing senses
of what a user 'needs to know'.  In order to function responsibly in
this e-mail enabled world of ours, users must be able to differentiate
between executables and documents.  Period.  To that end, however, user
interfaces must be clear and explicit when it comes to helping the user
differentiate the two.

> But hey, it's not like we haven't known this ever since the first Outlook
> worm, and it could've been solved for years.

Oh, sure, MS completely dropped the ball on Outlook and OE -- but
consider that this would only prevent e-mail worms, not user-distributed
'old-school' viruses.  Only user education could stop those.

take care,

Cael


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ