rick at linuxmafia.com
Mon Jan 8 12:28:59 PST 2007
Quoting Joe Buck (Joe.Buck at synopsys.COM):
> But if remote exploits become known in Linux distributions...
That would be, of course, _specificially_ remote exploits that are
triggerable from public networks, that exist in code that is widely run
on machines exposed to public data, and that remain unpatched following
discovery of the vulnerability and development of the exploit.
> And these exploits have occurred and been used in the past; back in
> the Red Hat 6 days (I think), there was a hole in ssh that was widely
> exploited, and one of my colleagues had a home machine that was taken
> over; evidently the bad guy was using my colleague's box to attack other
RHL 6.x was about the low point in maintenance of commodity Linux
machines exposed to public networks, because (1) RHN (and thus
semi-automated patching) wasn't available until RHL 7.0 (2000-09-25),
(2) default iptables scripts weren't part of the installation until
RHEL 7.3 (2002-05-06), and (3) several Typhoid Mary daemons were still
part of the distro -- BIND8, lpd/lprNG, wu_impad, wu_ftpd, and the worst
releases of OpenSSL (e.g., the 0.9.6 series).
Actually, relatively few systems were compromised on account of the
buggy OpenSSH/OpenSSL versions of 2001-2002, mostly because the problem
was so well known, at first, but then also because of the beneficial
effect of RHN, as that kicked in and 6.x boxes were upgraded or retired.
No offence to your colleauge, but he was more than a bit asleep at the
Probably a lot _more_ 6.x systems were compromised because of buggy,
obsolete versions of BIND8 and lpd/lprNG being exposed to public
networks than were caused by continued use of buggy, unupgraded SSHd
versions -- but only about 20,000 or so, out of an estimated 10-20
million Linux machines on public networks, at that time.
Given how scandalously badly run not only RHL but also nearly all other
distros were at that time, I'd dare say that things are in general a
great deal better, these days -- in the big picture. Even the less
with-it distros' security teams get their updates out, in general, long
before discovered remote vulnerabilities are exploitable -- and, these
days, I pay more attention to local privilege-escalation paths and buggy
user apps that handle public data (Web browsers, sundry AV software),
than I do to threats from buggy network daemons.
Still, avoiding sucky code and marketroid-touted bloatware is always
worthwhile, and will keep you from having to be on stupid patch-policy
treadmills in the first place.
 Whose main initial benefit was preventing oblivious people from
exposing print daemons, NFS, and Samba to public access by accident,
which happened depressingly often before that.
 One might ask how your colleague was so all-fired certain that it
was an OpenSSH bug that got his machine r00ted. Many people, in those
times _and_ in the present, jump to bad, unsupportable conclusions about
the vector of attack after the fact, that being actually a difficult
problem. It often becomes apparent after forensics that the avenue of
entry was something else entirely. Often, it was actually theft of
exposed ssh tokens on an already compromised host elsewhere, as was the
case with an unnamed local Linux company r00ted because dumbass
sysadmins were in the habit of ssh'ing out from the sensitive company
network to shells.sourceforge.net^W^W^W^W^Wa public shell server and
then doing ssh/scp actions _inbound_ into the company network.
Cheers, I remember Fred, 1919 - 2005.
Rick Moen http://linuxmafia.com/faq/Essays/fred.html
rick at linuxmafia.com
More information about the svlug