Gentoo Archives: gentoo-desktop

From: Roman Zilka <zilka@×××××××.cz>
To: gentoo-desktop@l.g.o
Subject: Re: [gentoo-desktop] Vulnerabilities on an RFC-1918 masqueraded Linux box.
Date: Thu, 24 Mar 2011 09:31:03
Message-Id: 20110324102926.935d0152.zilka@fi.muni.cz
In Reply to: Re: [gentoo-desktop] Vulnerabilities on an RFC-1918 masqueraded Linux box. by Lindsay Haisley
1 Lindsay Haisley (Wed, 23 Mar 2011 13:46:37 -0500):
2 > On Wed, 2011-03-23 at 10:44 +0100, Roman Zilka wrote:
3 > > Apart from that, you may once in a while get tempted to open a piece of
4 > > spam which just happens to look so legitimate. And this item happened
5 > > to contain a 1x1 pixel white image which abused a hole in libmng which
6 > > you'd always ignored, because you just never view mng files.
7 >
8 > I think you mean "libpng", not "libmng". I can't find any references to
9 > the latter.
10
11 I actually did mean libmng - it's a good example exactly because it's
12 so unpopular, yet exists on real systems. As for the reference, see
13 `emerge -pv libmng`. Also possibly interesting: `equery d libmng`,
14 although it only shows 1st level deps. Recursive traversal suggested
15 for more insteresting info on what can be potentially broken into when
16 a bug exists in libmng. On my system, for instance, qt-gui depends on
17 libmng and quite a number of everyday desktop apps depend on qt-gui. I
18 use the most common desktop Gentoo profile and have no mng-related USE
19 flags explicitly on/off.
20
21 > This exploit is apparently a design error in the library
22 > and is rated as being of low risk for Linux. You can get your Linux
23 > desktop DoS'd, apparently, but I find no reference to a viral infection
24 > or a wider system compromise. Reboot and carry on :-)
25
26 This looks like you're thinking about the library as having
27 _a_ security hole. Of course, nobody knows how many holes it has in
28 reality, but even those that have been discovered so far are multiple.
29
30 Also note that libmng was just an example. Everything has bugs.
31
32 > My hypothetical question said "Please cite specific viruses/trojans"
33 > which can affect a Linux desktop box.
34
35 I wrote a thesis on these and I can tell you there are plenty. I'll
36 ask you to ref. to Google or a nearby bookstore, as I don't want this
37 to turn into a chat / lecture on a general topic, or into an academic
38 paper with proofs of every other claim. Neither is the format of this
39 mailinglist.
40
41 > There's a difference between an
42 > exploit vulnerability which can open up a box from the inside to
43 > intrusion, and persists across reboots, and a vulnerability via an open
44 > port or exposed service which requires that the services be accessible
45 > from the Internet cloud. A javascript which can lock a box into an
46 > infinite loop, or a libpng vulnerability which can effectively DoS a box
47 > doesn't rise to this level.
48
49 DoS vulns are a subset. Arbitrary (malicious) code execution vulns are
50 another, and a much scarier one.
51
52 > Can we assume that there's no port exposure
53 > in a box masqueraded on a RFC1918 network? I'm not sure, which is why I
54 > posed the question.
55
56 There may be no port exposure from the outside indeed. But I gave
57 examples of situations when that doesn't matter.
58
59 > With perhaps a very few exception these exploits are aimed at MS Windows
60 > boxes. Recent Flash vulnerabilities, for instance, are listed as
61 > affecting "Adobe Flash Player 10.1.82.76 and earlier versions for
62 > Windows, Macintosh, Linux, and Solaris, and Adobe Flash Player
63 > 10.1.92.10 for Android" but the report goes on to say that "There are
64 > reports that this vulnerability is being actively exploited in the wild
65 > against Adobe Flash Player on Windows." No mention of Linux, and I can
66 > find no references to a web or email borne exploit found in the wild
67 > that actually generates an *infection* on a Linux box. Consider this a
68 > challenge, if you will, since I'd love to be proved wrong on this last
69 > point and learn something.
70
71 Again, countless lines of tutorials, books, theses, papers and reports
72 of all sorts have been written on exploiting arbitrary code execution
73 vulns on Linux. On this mailinglist there's nothing else for me to do
74 but to ask you to refer to any suitable external source on Linux
75 security. In fact, I literally suggest that you do, provided you do
76 business on your PC.
77
78 By the way, you don't even need to see one specific malicious PDF file
79 that'll abuse something in a buggy Acrobat. All you need to know is
80 that Acrobat has an arbitrary code execution vuln. It's up to you to
81 decide what code exactly will be run - a shellcode, a keylogger, a
82 hello-world, a DoS attack, a spam bot, you name it. Try looking around
83 the web for those. Make sure that your browser settings, you Google
84 settings and your current ISP benevolence allow for reaching
85 underground sites. Your search for info will be even faster that way.
86
87 > One of the reasons I use Linux is because real infections of any sort
88 > via email or web are extremely rare. This isn't to say that they're
89 > non-existent, and there's no such thing as absolute security, but
90 > prevention of such problems is a matter of keeping up with CERT
91 > bulletins. A quick search on US-CERT's website is pretty reassuring.
92 > Searching for Linux turns up virtually nothing from the past several
93 > years, although I do know that there was a nasty glibc vulnerability not
94
95 I don't know what and how where you looking for, but re-consider this
96 with a clear mind. It's obviously unrealistic. I hope you don't believe
97 that.
98
99 > > Also, you mentioned earlier that you access various VPNs. I don't know
100 > > much about VPNs, and topologies and configurations may clearly vary
101 > > broadly, but I suppose there can be a setting such that your PC will
102 > > get exposed to direct traffic from the VPN peers. NAT or not NAT.
103 >
104 > Absolutely! If a skilled cracker were to compromise one of my servers,
105 > or one of my clients' servers to which I'm connected via VPN, then I'm a
106 > sitting duck, assuming said cracker has the skill to figure out how to
107 > traverse the VPN and compromise _my_ Linux security. My VPN's are wide
108 > open, for a reason. My question is a hypothetical one, however,
109 > regarding general security, and the issue of VPNs relates only to my
110 > particular setup. And this involves an "exploit" of a connected box,
111 > not a virus/trojan infection, as per my question.
112
113 It doesn't have to be a cracker in person.
114
115 If you limit your attention to viruses/rootkits only, you're missing
116 out on the other ways your Linux box can be penetrated.
117
118 > One always learns far more from one's failures than from one's
119 > successes. My Linux servers _have_ been hacked. The biggest hole on my
120 > servers is PHP, and all the break-ins on them have been via large PHP
121 > mega-apps (e.g. WordPress). Most recently we had a customer's WordPress
122 > installation compromised and the attacker was trying exploit a known
123 > vulnerability in the local glibc. He managed only to totally DoS the
124 > box and I had to get an on-site admin to re-boot it. I've locked down
125 > execute perms on wget, which is what most of these black-hats use to
126 > load in their cracking tools, and we've had zero problems since. But
127 > this is server stuff, and OT for this forum.
128
129 For the sake of security of that server, I hope you skipped a number of
130 other steps you took.
131
132 But once again - I suggest quitting this discussion. It's getting way
133 off-topic, too general and unfit for this mailinglist, as all these
134 questions can be answered by checking sources someone else has
135 previously spent their time on writing. That being said, I myself will
136 stick to the boot-up issue stuff only.
137
138 -rz

Replies

Subject Author
Re: [gentoo-desktop] Vulnerabilities on an RFC-1918 masqueraded Linux box. Lindsay Haisley <fmouse-gentoo@×××.com>