Re: Public Policy and Consumer ISP Hygiene (was Comcast pop-ups)

[Michael Collins <mcollins () aleae com>]

On Oct 13, 2009, at 9:02 AM, Valdis.Kletnieks () vt edu wrote:

> On Sun, 11 Oct 2009 23:31:08 CDT, Dan White said:
>
> > 1) Educating users on proper use of anti-virus and anti-malware  
> > tools - and
> > being ADHD about installing OS updates.
>
> No, you *don't* want them being ADHD about OS updates. You want them
> to be obsessive-compulsive about it.  Somebody wit OCD will be going
> back and checking "Am I patched? Did I patch in the last hour? I  
> better
> check again to be sure".  Somebody with ADHD will end up visiting
> http://windowsupdate.microsohlookachicken.com

Patching isn't a magic solution, much as I wish it was.  As we've  
mentioned already in this thread, there are folks who are required by  
law to patch their systems back to vulnerable levels.  Of course, this  
also assumes that the patch works...  The other problem with this,  
really, is that user education operates as a selection process for  
attackers.  Just like malware has gotten more sophisticated, the cons  
are getting more psychologically sophisticated as well.

The other problem, here, is that it assumes that attacks are  
necessarily vul-based (or, more precisely os-vul based).  Droppers  
don't have to be, and the most common ssh attacks we see are all  
password-list based.

> > 3) Doing what we can to develop and increase our participation in a  
> > public
> > key infrastructure and IPSEC.
>
> Unfortunately, most of the problems we have would *not* be fixed  
> with more
> crypto and IPSEC (with the exception of closing down unencrypted  
> wireless and
> making the standard there WPA2 or a better follow-on).  I mean,  
> *seriously*,
> how often do you hear of successful sniffing attacks on copper or  
> fiber,
> compared to the number of attacks where a keystroke logger or  
> website hack
> got the unencrypted goods at the endpoint?

This is, of course, the great achievement of cryptography (as long as  
you ignore the whole we're-not-really-sure-it-works problem).  It's so  
well defined that no attacker bothers hitting a cryptosystem.

> You want to fix something - come up with a good way to enhance the  
> trust for
> websites that load from multiple places.  Go read Schneier's  
> "Secrets and Lies",
> he has a good chapter on SSL snake oil, but to sum it up with a re- 
> quote
> of an example from yesterday:
>
> If I'm on msnbc.msn.com, and click a link that takes me to  
> discovery.com,
> what reason does my browser have to trust the Flash content that gets
> loaded from mstories.vo.llnwd.net?  (Hint - your scheme has to work  
> even
> if discovery.com is compromised - if the hacker can change the link,  
> there's
> a good chance that if you depend on a digital signature of the page  
> containing
> the link, he can re-sign the page as well.  Probably not for  
> discovery.com,
> which likely has separate devel and prod machines and the signing  
> can happen
> on the devel boxes - but there's a *lot* of "update in place"  
> websites that
> would almost certainly have the signing keys on the webserver.  Bad  
> idea,
> I know, but it's gonna happen.

Heh, we're cycling back to the eternal problem here - as security  
people, our fundamental job is to ruin performance for everyone else.   
CDN's do depend on nasty DNS hacking.



> _______________________________________________
> Fun and Misc security discussion for OT posts.
> https://linuxbox.org/cgi-bin/mailman/listinfo/funsec
> Note: funsec is a public and open mailing list.

Mike Collins
mcollins () aleae com



_______________________________________________
Fun and Misc security discussion for OT posts.
https://linuxbox.org/cgi-bin/mailman/listinfo/funsec
Note: funsec is a public and open mailing list.