[vox] Fwd: LAZY WORLD TO LINUX PURISTS: F.U. ?

[Bill Kendrick]

Eric(right?) posted from a non-subscribed address, since he responded
to something that I cross-posted to both SacLUG and LUGOD.  (Sorry :) )

Since SacLUG's list is publically readable, I'm figuring there's no
problem with passing it along to LUGOD, even if he didn't _mean_ to,
in the first place.

-bill!

----- Forwarded message from vox-bounces at lists.lugod.org -----

The attached message has been automatically discarded.
Date: Fri, 10 Apr 2009 18:33:09 -0700 (PDT)
Subject: LAZY WORLD TO LINUX PURISTS: F.U. ?

Microsoft would prefer that everyone upgrade to Vista (soon to be Windows7), but a lot of customers were "annoyed" at "too much security" in the early versions of Vista.

Ironically, Microsoft tried to give the world what Linux folks wanted: better security (in Vista), and the world basically said "F.U." back to Microsoft.

There is a lesson there for Linux people:

The same reasons that people run Windows are the same reasons that PCs are not maintained well, which is why most people don't want Linux either: 

  LAZINESS. SLOTH. INDOLENCE. VARIOUS OTHER SNAKE PITS OF HUMAN NATURE.

Note: the "conficker worm" was a "April Fools" thing. As the article below indicates, the "underlying hole" (no pun intended!) was patched by MS many months before April 1, 2009.

The "real" question, which has been asked by many "responsible" windows techies for years, is:

"Why don't people keep their machines patched?"

I was surprised to read that "conficker" mainly affected organizations, not "home" users. Apparently there are a lot of "organizations" that have cr*ppy patch management. ??? argh.

"Windows Secrets" had extensive coverage about the "autoplay" fiasco before 4/1/09, and the absurd length of time it took MS to "do the right thing".

http://windowssecrets.com/2009/03/05/02-AutoRun-patch-a-long-time-coming-for-XP-users

Here is the putrid, but necessary, procedure that everyone now has to do on Win XP boxes to be "more secure":

---excerpt---

How to apply the patches and control AutoRun 

If you followed the instructions in Scott's 2007 article to block AutoRun by adding a Registry key, you should remove the key before applying the Microsoft AutoRun patch to prevent any possible interaction. Take the following steps for complete protection:

Step 1. Remove the @SYS line from the Registry, if you added it. In Windows XP, click Start, Run. (In Vista, click Start.) Type regedit and press Enter. In the left pane, navigate to and select the following key:

HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows NT \ CurrentVersion \ IniFileMapping \ Autorun.inf

Press the Del key to remove the key. Close the Registry Editor.

Step 2. Install the patch described in KB article 953252 (for Vista and Windows Server 2008) or 967715 (for XP, 2000, and Server 2003).

Step 3. For security reasons, it's strongly recommended you disable AutoRun for all devices. In non-Home versions of XP and Vista, use the Group Policy Editor. In XP, click Start, Run. (In Vista, click Start.) Type gpedit.msc and press Enter. In the left pane, under Computer Configuration, expand Administrative Templates.

In XP Professional, select System in the right pane under Administrative Templates, right-click Turn off Autoplay in the right pane, and choose Properties. Click Enabled, select All drives in the "Turn off Autoplay" box, click OK, and close the Group Policy Editor.

In Vista Business and higher, expand Windows Components and select AutoPlay Policies. In the right pane, double-click Turn off Autoplay, click Enabled, choose All drives in the drop-down menu next to "Turn off Autoplay on," click OK, and close the Group Policy Editor.

To disable AutoRun in the Home versions of XP and Vista ??? which don't have the Group Policy Editor ??? use the Registry Editor. In XP, click Start, Run. (In Vista, click Start.) Type regedit and press Enter. Navigate to and select the following key:

HKEY_LOCAL_MACHINE \ Software \ Microsoft \ Windows \ CurrentVersion \ Policies \ Explorer

In the right pane, double-click NoDriveTypeAutoRun, enter 0xFF in the "Value data" field, make sure Hexadecimal is selected under Base, click OK, and exit the Registry Editor.

Step 4. If you ever need to re-enable AutoRun for a certain system, open the Group Policy Editor (on non-Home versions of Windows) or the Registry Editor (Home versions). Then follow the instructions in KB article 967715 (for XP, 2000, and Server 2003) or 953252 (for Vista and Windows Server 2008) to return AutoRun to its default state or customize its settings. AutoRun can be configured, for instance, to work differently for CD-ROMs than for other media.
Once you've disabled AutoRun, you'll have to use Windows Explorer to access data files on the USB memory devices and optical media you insert in your PC. If you load a disc that contains audio or video, you may want to open your favorite media player to run the content. However, this is a small price to pay for the security edge you gain by disabling AutoRun.

---end excerpt---


Comment: BARFOLA.

(I now have to do this for dozens of machines at work. Vile stuff.)


Anyways, hopefully all this has made a few Linux people "feel better" now that their sense of glib superiority over the unwashed, unrefined masses has been assuaged.

hehehehe.

---- Original message ----
>Date: Thu, 9 Apr 2009 21:33:28 -0700
>From: Bill Kendrick <nbs at sonic.net>  
>Subject: [Lug-nuts] Fwd: Got worm ? ? ?  
>To: LUGOD <vox at lists.lugod.org>,SacLUG lug-nuts <lug-nuts at saclug.org>
>
>
>Seen on SF-LUG.
>
>----- Forwarded message from Rick Moen -----
>
>Date: Thu, 9 Apr 2009 18:42:08 -0700
>From: Rick Moen
>Subject: Re: [sf-lug] Got worm ? ? ?
>
>Elkhorn wrote:
>
>> Nice analysis, by SRI, of the "Conficker" MS-Windows worm.
>[...]
>> http://mtc.sri.com/Conficker/
>> http://mtc.sri.com/Conficker/addendumC/
>
>(Actually, Elkhorn didn't say "MS-Windows worm".  I inserted the
>qualifier to point out that Elkhorn was posting about a non-Linux
>problem.)
>
>
>I'm revisiting this topic because I thought it might be interesting to 
>comment on the SRI report from a _Linux_ perspective.  That might make
>an interesting change from the usual.
>
>So, (1) what's a worm, and how does it differ from viruses and trojan
>horses?  And then, (2) how does it come to get _run_, anyway?  For the first
>question, have a look at this undergrad paper by a Mr. David Stone, 
>"Spyware/Viruses in Linux":  http://nnucomputerwhiz.com/linux-virus.html
>(Shameless self-promotion alert:  Stone's paper tests, very
>impressively, some assertions about Linux malware in the Web pages of
>yr. humble servant.)
>
>Stone's description is pretty accurate, and concise:
>
>   The nastiest viruses are the ones that exploit remote security holes
>   in the operating system and use those to infect a computer over the
>   network.  The infected computer will then try to infect more computers
>   and so on.  Viruses that behave in this way are called worms. 
>
>
>Question #2, "How does it come to get run?", is always, always, always
>the most-vital question with malware -- and the fact that the IT press
>and the security industry tend to give _bad or no_ answers to that
>question for MS-Windows malware should be setting off alarms.  It's one
>of many indicators of a horribly broken situation, which Linux users
>would not put up with.  
>
>It turns out, Conficker's vector of attack is a _little_ easier to track
>down than that of many pieces of MS-Windows malware -- which is to say,
>you can find at least vague descriptions without huge difficulty, and 
>pry the real details out if you're very determined.
>
>Ever since the MS-Windows NT family replaced the prior MS-Windows
>95/98/ME family (which was just MS-DOS 7.x with MS-Windows 4.x glued
>on top), all MS-Windows systems have automatically run an RPC portmapper
>network service.
>
>"Say what?", you said.  I'm referring to a network service (daemon) 
>that freely hands out, on any network interface the machine has
>(including modems) Remote Procedure Call port assignments usable to
>reach various other network services that might be (or might not be)
>also running on that machine.
>
>In Unix-type operating systems, we've had RPC portmapper daemons
>available and studied for a long time:  The concept was first invented
>in BSD Unix in the 1980s, but Sun Microsystems later invented the
>standard design, and Linux closely imitated that.  On the basis of decades
>of experience it's known to be inherently dangerous to security, for a
>couple of reasons:  1.  Because the port assignments it hands out cannot 
>be predicted, it makes port/address firewalling difficult.  2.  Like any 
>other advertised network service, it's an exposed point of outside
>attack by bad guys.
>
>For those reasons, RPC-based network services on Unix (chiefly NIS and
>NFS) are considered too dangerous for anything other than carefully
>protected, isolated networks.  In rare cases where questionable calls
>are made by "desktop" programmers [**COUGH** "fam" in GNOME **COUGH],
>it's trivial to set the rpc.portmap daemon process to be accessible from
>localhost only.  _And_ it's very easy to determine what's going to not
>work if you shut it down.
>
>Back to Microsoft:  Having learned little-to-nothing from 40 years of
>Unix history, they made all -- _all_ -- NT-family machines run a
>portmapper, something called "Server Service".
>
>Can you lock the "Server Service" daemon process to localhost?  Nope.
>
>Can you determine what'll break, and if you care, if you were to shut
>_off_ the "Server Service" daemon?  Nope.
>
>
>One of the longest-ago and most bitter lessons of network security is
>that any process that must deal in public data must carefully _validate_
>that data before parsing it.  "Validate" means making sure data is of
>the allowed/expected types/lenghths/contents only, so that subsequent 
>code cannot be subverted by overpowering it with wrong / malformed data.
>
>An RPC portmapper daemon would be a classic case of where data input
>validation would be utterly crucial, and an incredibly picky input
>parser would be the very first and most important piece you'd write.
>
>Which brings us back to Conficker:  Delve through dozens of mostly
>content-free articles on the subject, and you eventually come across
>things like:
>
>    executes arbitrary code via a crafted RPC request that triggers the
>    overflow during path canonicalization
>
>Hullo?  How could a "crafted RPC request" trigger a buffer overflow?
>That would be possible only if....
>
>Egads.  Microsoft Corporation put out a security-crucial network daemon
>on each and every MS-Windows machine, one that cannot be locked to
>localhost only, and cannot be safely prevented from starting because 
>you don't know what would break, that had _no input validation_!
>
>Furthermore, according to even such carefully semi-informative notices
>as http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2008-4250 , this
>complete and total failure to validate crucial public data was still
>present in Win2k Service Pack 4, WinXP Service Pack 3, Windows Server
>2003 Service Pack 2, Vista Service Pack 1, Windows Server 2008, and
>Windows 7 Pre-Beta.  In other words, they finally got around to 
>looking at input validation after 14 years!
>
>If any Linux distro had been that reckless with crucial network issues,
>and moreover had needlessly exposed every _desktop_ system to those 
>issues for a decade-plus, their staff would have hidden in shame.
>
>But wait!  There's more.  The "fix" came out in hotfix patches and then 
>service packs, around October 2008.  In Linux terms, this would have
>been an urgent, top-priority fix that would be _pushed_ out to Linux
>systems and shouted from the rooftops.  We would have been busting our
>butts to _shut down_ our RPC portmappers instantly, and then replace 
>them with competently written code the same day.
>
>And my calendar says:  April 2009.  Six months after the fixes, and
>they're talking about a worldwide exploit of vulnerable RPC network code?
>
>
>I said I'd look at the SRI pages.  So:
>
>> From late November through December 2008 we recorded more than 13,000
>> Conficker infections within our honeynet, 
>
>OK, suggests that the September 2008 vulnerability announcements (and
>hotfix announcements) were followed by appearance in public of a canned
>exploit a month later.  Is anyone surprised?
>
>> The exploit employs a specially crafted remote procedure call (RPC)
>> over port 445/TCP, which can cause Windows 2000, XP, 2003 servers, and
>> Vista to execute an arbitrary code segment without authentication.  
>
>The SRI report is better than most in the "How does it come to get
>run?" category, but still fails to address the obvious questions:  
>_Why_ is there a portmapper at all, especially on desktop systems?
>Why isn't it locked to localhost by default?  What relies on it?
>What were they smoking when they decided to not validate input data on a
>network daemon exposed to public code?
>
>> The exploit can affect systems with firewalls enabled, but which
>> operate with print and file sharing enabled. 
>
>Suggests that these "firewall" leave the RPC portmapper exposed to
>public data, probably on grounds of Microsoft's SMB implementation 
>requiring it be thus exposed. 
>
>Note that Samba, the interoperable open-source implementation of SMB
>file and print sharing, does not require RPC service of any sort.  
>
>> those Windows PCs that receive automated security updates have not
>> been vulnerable to this exploit.
>
>The paper refers obliquely, but doesn't detail, the reasons why many
>sites, even those that are very security conscious, are slow to apply 
>Microsoft hotfixes and service packs as a matter of policy:  breakage.
>Because of poor modularity (poorly defined, unstable interfaces) in the
>OS and app stack, sites are afraid to apply patches:  They don't know 
>what else will break.
>
>Again the Linux world would not put up with that situation.
>
>
>The SRI paper spends a lot of time talking about what Conficker does
>after it's been run with system root authority.  From a Linux
>perspective, that's pretty much academic, because it's game over if a
>Linux host is believed to be root-compromised:  You yank the power cord,
>boot up trusted boot media (e.g., a live CD), study the inactive system
>to make sure you know what happened and how to prevent its recurrence, 
>copy off the datafile and a reference copy (not to be reused) of the
>compromised machine configuration, and build a replacement host from
>scratch, carefully avoiding trusting anything executable or any conffile
>or dotfile from the burned host.
>
>
>> NetBIOS Share Propagation:  Conficker B exploits weak security
>> controls in enterprises and home networks to find additional
>> vulnerable machines through open network shares and brute force
>> password attempts using a list of over 240 common passwords. 
>
>As usual, the SRI paper fails to address:  Why are NetBIOS-share 
>authentication datbases permitted to accept weak passwords?  Haven't
>they heard of the system crack libraries?
>
>
>> USB Propagation:  Finally, Conficker B copies itself as the
>> autorun.inf to removable media drives in the system, thereby forcing
>> the executable to be launched every time a removable drive is inserted
>> into a system.
>
>And why does Microsoft still have an autorun mechanism defaulting to
>enabled after nothing more than the insertion of media?  Have they
>learned nothing?
>
>
>To be fair, none of these questions is in-scope for the SRI study's
>intended coverage.  My point really is that _nobody_ in the Microsoft
>world routinely asks those questions.  All of the indicated types of
>incompetence are accepted without objection and accepted as unavoidable
>reality -- and all of them would instantly raise red flags in the Linux
>community.
>
>----- End forwarded message -----
>
>-- 
>-bill!
>Sent from my computer
>_______________________________________________
>Lug-nuts mailing list
>Lug-nuts at saclug.org
>http://www.leibmanland.com/cgi-bin/mailman/listinfo/lug-nuts


----- End forwarded message -----

-- 
-bill!
Sent from my computer