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 |