Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-desktop
Navigation:
Lists: gentoo-desktop: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-desktop@g.o
From: Roman Zilka <zilka@...>
Subject: Re: Vulnerabilities on an RFC-1918 masqueraded Linux box.
Date: Thu, 24 Mar 2011 10:29:26 +0100
Lindsay Haisley (Wed, 23 Mar 2011 13:46:37 -0500):
> On Wed, 2011-03-23 at 10:44 +0100, Roman Zilka wrote:
> > Apart from that, you may once in a while get tempted to open a piece of
> > spam which just happens to look so legitimate. And this item happened
> > to contain a 1x1 pixel white image which abused a hole in libmng which
> > you'd always ignored, because you just never view mng files.
> 
> I think you mean "libpng", not "libmng".  I can't find any references to
> the latter.

I actually did mean libmng - it's a good example exactly because it's
so unpopular, yet exists on real systems. As for the reference, see
`emerge -pv libmng`. Also possibly interesting: `equery d libmng`,
although it only shows 1st level deps. Recursive traversal suggested
for more insteresting info on what can be potentially broken into when
a bug exists in libmng. On my system, for instance, qt-gui depends on
libmng and quite a number of everyday desktop apps depend on qt-gui. I
use the most common desktop Gentoo profile and have no mng-related USE
flags explicitly on/off.

> This exploit is apparently a design error in the library
> and is rated as being of low risk for Linux.  You can get your Linux
> desktop DoS'd, apparently, but I find no reference to a viral infection
> or a wider system compromise.  Reboot and carry on :-)

This looks like you're thinking about the library as having
_a_ security hole. Of course, nobody knows how many holes it has in
reality, but even those that have been discovered so far are multiple.

Also note that libmng was just an example. Everything has bugs.

> My hypothetical question said "Please cite specific viruses/trojans"
> which can affect a Linux desktop box.

I wrote a thesis on these and I can tell you there are plenty. I'll
ask you to ref. to Google or a nearby bookstore, as I don't want this
to turn into a chat / lecture on a general topic, or into an academic
paper with proofs of every other claim. Neither is the format of this
mailinglist.

> There's a difference between an
> exploit vulnerability which can open up a box from the inside to
> intrusion, and persists across reboots, and a vulnerability via an open
> port or exposed service which requires that the services be accessible
> from the Internet cloud.  A javascript which can lock a box into an
> infinite loop, or a libpng vulnerability which can effectively DoS a box
> doesn't rise to this level.

DoS vulns are a subset. Arbitrary (malicious) code execution vulns are
another, and a much scarier one.

> Can we assume that there's no port exposure
> in a box masqueraded on a RFC1918 network?  I'm not sure, which is why I
> posed the question.

There may be no port exposure from the outside indeed. But I gave
examples of situations when that doesn't matter.

> With perhaps a very few exception these exploits are aimed at MS Windows
> boxes.  Recent Flash vulnerabilities, for instance, are listed as
> affecting "Adobe Flash Player 10.1.82.76 and earlier versions for
> Windows, Macintosh, Linux, and Solaris, and Adobe Flash Player
> 10.1.92.10 for Android" but the report goes on to say that "There are
> reports that this vulnerability is being actively exploited in the wild
> against Adobe Flash Player on Windows."  No mention of Linux, and I can
> find no references to a web or email borne exploit found in the wild
> that actually generates an *infection* on a Linux box.  Consider this a
> challenge, if you will, since I'd love to be proved wrong on this last
> point and learn something.

Again, countless lines of tutorials, books, theses, papers and reports
of all sorts have been written on exploiting arbitrary code execution
vulns on Linux. On this mailinglist there's nothing else for me to do
but to ask you to refer to any suitable external source on Linux
security. In fact, I literally suggest that you do, provided you do
business on your PC.

By the way, you don't even need to see one specific malicious PDF file
that'll abuse something in a buggy Acrobat. All you need to know is
that Acrobat has an arbitrary code execution vuln. It's up to you to
decide what code exactly will be run - a shellcode, a keylogger, a
hello-world, a DoS attack, a spam bot, you name it. Try looking around
the web for those. Make sure that your browser settings, you Google
settings and your current ISP benevolence allow for reaching
underground sites. Your search for info will be even faster that way.

> One of the reasons I use Linux is because real infections of any sort
> via email or web are extremely rare.  This isn't to say that they're
> non-existent, and there's no such thing as absolute security, but
> prevention of such problems is a matter of keeping up with CERT
> bulletins.  A quick search on US-CERT's website is pretty reassuring.
> Searching for Linux turns up virtually nothing from the past several
> years, although I do know that there was a nasty glibc vulnerability not

I don't know what and how where you looking for, but re-consider this
with a clear mind. It's obviously unrealistic. I hope you don't believe
that.

> > Also, you mentioned earlier that you access various VPNs. I don't know
> > much about VPNs, and topologies and configurations may clearly vary
> > broadly, but I suppose there can be a setting such that your PC will
> > get exposed to direct traffic from the VPN peers. NAT or not NAT.
> 
> Absolutely!  If a skilled cracker were to compromise one of my servers,
> or one of my clients' servers to which I'm connected via VPN, then I'm a
> sitting duck, assuming said cracker has the skill to figure out how to
> traverse the VPN and compromise _my_ Linux security.  My VPN's are wide
> open, for a reason.  My question is a hypothetical one, however,
> regarding general security, and the issue of VPNs relates only to my
> particular setup.  And this involves an "exploit" of a connected box,
> not a virus/trojan infection, as per my question.

It doesn't have to be a cracker in person.

If you limit your attention to viruses/rootkits only, you're missing
out on the other ways your Linux box can be penetrated.

> One always learns far more from one's failures than from one's
> successes.  My Linux servers _have_ been hacked.  The biggest hole on my
> servers is PHP, and all the break-ins on them have been via large PHP
> mega-apps (e.g. WordPress).  Most recently we had a customer's WordPress
> installation compromised and the attacker was trying exploit a known
> vulnerability in the local glibc.  He managed only to totally DoS the
> box and I had to get an on-site admin to re-boot it.  I've locked down
> execute perms on wget, which is what most of these black-hats use to
> load in their cracking tools, and we've had zero problems since.  But
> this is server stuff, and OT for this forum.

For the sake of security of that server, I hope you skipped a number of
other steps you took.

But once again - I suggest quitting this discussion. It's getting way
off-topic, too general and unfit for this mailinglist, as all these
questions can be answered by checking sources someone else has
previously spent their time on writing. That being said, I myself will
stick to the boot-up issue stuff only.

-rz


Replies:
Re: Vulnerabilities on an RFC-1918 masqueraded Linux box.
-- Lindsay Haisley
References:
Vulnerabilities on an RFC-1918 masqueraded Linux box.
-- Lindsay Haisley
Re: Vulnerabilities on an RFC-1918 masqueraded Linux box.
-- Roman Zilka
Re: Vulnerabilities on an RFC-1918 masqueraded Linux box.
-- Lindsay Haisley
Navigation:
Lists: gentoo-desktop: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Vulnerabilities on an RFC-1918 masqueraded Linux box.
Next by thread:
Re: Vulnerabilities on an RFC-1918 masqueraded Linux box.
Previous by date:
KDE march meeting 31/3/11
Next by date:
Re: Vulnerabilities on an RFC-1918 masqueraded Linux box.


Updated Jun 28, 2012

Summary: Archive of the gentoo-desktop mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.