Anyone see a game changer here?

Keith Medcalf kmedcalf at dessus.com
Sat Jan 16 16:34:45 UTC 2010


>Personally I was amused at people adding cement to USB ports to mitigate
>against the "removable media threat".  The issue I see is people forget
>that floppies posed the same threat back in the day.

Do you mean the "AutoRun" threat, since this sort of thing is usually done by people who (a) run M$ Winders and (b) do not know how to turn off the really annoying "helpful" features created by the clueless idiots in Redmond ... and those idiots keep on creating more and more security hole "features" that have to be disabled.

Someone should tell the idiots who design API's that API's are designed to be used -- and they will be used to do what it was designed to do -- and if that design constitutes a security flaw, then it will be used as such and the only solution is to stop designing stupid APIs.  The most laughable example is the creation of API hooks into the kernel for use by AntiVirus vendors.  Unfortunately, these APIs can, by their very definition, be used by anyone who wants for any purpose they desire.

Personally I would prefer a secure kernel that cannot be tampered with or compromised by anyone.  Adding a deliberately designed security flaw to enable a third party to stay in business providing a partial plug for the deliberately designed hole is utter lunacy!

Back to removable media, AutoRun is, and always has been, completely trivial to completely, utterly and irrevocably disable -- and I have been doing so since, well, since this idiotic mis-feature first appeared somewhere in the early 90's.

The same applies to other crap-ware vectors such as Flash.

Just because some people are slow or do not pay attention to what has been going on in the world for 20 years on, does not make these "new".

Its like dogs -- they have been around for thousands of years.  Some people just don't notice that they have teeth until they, through their own stupidity, get bitten by one.

Now, back to your regularly scheduled programming ...








More information about the NANOG mailing list