back to article Evildoers can now turn all sites on a Linux server into silent hell-pits

An advanced Linux malware strain can automatically hijack websites hosted on compromised servers to attack web surfers with drive-by-downloads. The software nasty targets machines running 64-bit GNU/Linux and a web server, and acts like a rootkit by hiding itself from administrators. A browser fetching a website served by the …


This topic is closed for new posts.
  1. Anonymous Coward
    Anonymous Coward

    How does one get infected with this particular nasty? Most system administrators know better than to install software outside of the repositories. How would this thing get on the server in the first place?

    1. Ben Tasker

      Exactly what I was wondering. Going to need privilege escalation to get itself into the kernel, and that's after getting onto the server and being run.

      How it gets there is as important as what it does, is it like the recent(ish) Mac malware that was only really a threat if users downloaded and ran it?

      It's still an interesting story, but comes across as scaremongering when the infection vector is left out.

      Right, moaning over, I'll go back to the article and see if there's a link I can click to find out!

      1. Ole Juul

        Something doesn't sound right

        It's still an interesting story, but comes across as scaremongering when the infection vector is left out.

        Exactly. Perhaps it's time to take bets.

      2. itzman

        Yeah..that's my puzzlement as well.

      3. ElReg!comments!Pierre

        Re: route of entry

        I guess that in a tagetted, spy-like scenario as the one described, the easiest way would be to put the nasty in a "legit" package by hacking the distro's official repositories (like what happened with FreeBSD recently). Actually that raises another question: does it run as a module (immediate effect, but easier to detect and eradicate) or does it require a reboot ( as a lot of Linux servers are only rebooted for kernel upgrades anyway that would make the malware mostly useless, but harder to detect/eradicate in the one-in-a-million case in which it would actually become active)?

    2. Nigel 11

      Infection route

      One route would be any bug in the kernel that allows an attacker to execute code as root. Such bugs usually have a short life, but a rootkit may outlast the bug that allowed it to install itself. Alternatively the bug may at present be known only to the black hats. Another route would be if they managed to hack into a developer's system and build their malware (or a bootloader for their malware) into a released package.

      1. Anonymous Coward
        Anonymous Coward

        Re: Infection route

        "bug in the kernel that allows an attacker to execute code as root"

        That's not really the point - it still has to get onto the system somehow - I think everyone is aware of priv. escalation bug possibilities

        1. YellowApple

          Re: Infection route

          Even with a privilege escalation bug, that information is not being provided, making all these scaremongering, FUD-filled articles about "OMG LINUX HAZ A ROOTKIT OMGOMG!!!!!1111one" rather worthless. I run a Debian server. I'd like to know how such a rootkit actually gets onto my machine.

      2. Anonymous Coward

        Re: One route would be ..

        > One route would be any bug in the kernel that allows an attacker to execute code as root.

        Except it isn't ...

        1. h4rm0ny

          Re: One route would be ..

          "Except it isn't ..."

          Isn't what? A possible route of infection? Yes - of course that's a possible route of infection. Do you think that there have never been privilege escalation flaws on GNU/Linux? If so, I seriously hope that you aren't a Linux sysadmin. Do you just never patch your Linux boxes because you believe there are no flaws and thus nothing to fix? All modern OSs have flaws discovered and need fixing.

          1. Vic

            Re: One route would be ..

            >> "Except it isn't ..."

            > Isn't what?

            It isn't a bug in the kernel.

            It's a kernel module that is being explicitly loaded. The kernel is doing exactly what it is supposed to do - running service modules that the sysad has asked it to run.


    3. Anonymous Coward
      Anonymous Coward

      Funny, but all the Android Malware stories have the same basic flaw. You need to be pretty darn stupid and disable things that clearly warn you that you are opening yourself up to problems.

      Yet the same sensationalist security companies (that are clearly running some special flavor of Debian called "squeezy") don't care, they just have something to sell you to fix it..

      1. h4rm0ny

        "that are clearly running some special flavor of Debian called "squeezy"

        Are you joking? Squeezy is the mainline latest stable release of Debian. I am running it here right now. It's about as far from being a "special flavour" as you can get. Educate yourself before you dismiss other people's work.

        1. Frumious Bandersnatch

          "that are clearly running some special flavor of Debian called "squeezy"

          I take it the OP was indirectly pointing out that the correct name for the release is "squeeze", not this mythical "squeezy" beast.

        2. Anonymous Coward
          Anonymous Coward

          No he's not joking.

          " Squeezy is the mainline latest stable release of Debian"

          No it is not. Squeeze is.

          "Educate yourself before you dismiss other people's work."


      2. I think so I am?


        Squeezy = Stable build

        Could you please put bazinga at the end in future because I couldn't tell if your a ding bat or being sarcastic

        1. h4rm0ny

          Re: Bazinga

          "Could you please put bazinga at the end in future because I couldn't tell if your a ding bat or being sarcastic"

          Funny - I think the same about your post. Squeeze is the current mainline stable build. The AC seemed to think "squeezy" (sic) was some "special flavour" used by Kapersky to discredit Linux (from the context of their post). So are you saying that the AC was right in their paranoia (they weren't) or that I shouldn't have corrected them? I suppose it's possible that the AC was simply mocking the typo of "Squeezey" instead of "squeeze", but given that it was in the middle of a rant about anti-virus labs trying to set up contrived scenarios, smart money is on them just not knowing much about Debian.


        2. NB

          Re: Bazinga

          Actually it's 'Squeeze'

    4. Anonymous Coward

      How would this thing get on the server?

      > How does one get infected with this particular nasty? Most system administrators know better than to install software outside of the repositories. How would this thing get on the server in the first place?

      Doesn't matter as long as they've got Linux, malware and rootkit in the one sentence. If it was Windows then it would be referred to as 'computer' malware ..

    5. El Andy

      If only that were true. Alas, as can be seen from the comments on any malware story on the Reg, far too many people actually believe that Linux is magically invulnerable to all these security issues and wouldn't actually think twice about installing a package from somewhere else if they though they needed it. Couple that with the lack of anti-malware software running on most Linux boxes and it's a very credible threat.

      1. h4rm0ny

        What's really depressing is that someone modded you down for that. Meaning they actually think that you're wrong to criticise people for thinking Linux is magically invulnerable. The tragic thing is that back when I first started using Linux, in the days when you had to compile everything yourself, nobody had that attitude. Okay, we knew it was safer than Windows in a lot of ways both because it was more obscure and because back then you had Windows 2000 and XP that didn't have decent security models. But you didn't have this zealotry.

        Linux seems to have acquired religious followers. Those of us who actually were around in the early days and probably know more about managing or programming on Linux than a lot of the Linux fan-people, get modded down by those who merely identify with the OS like its some sort of sect. Take Eadon for example - on a previous story they actually tried to make the argument that good programmers are those who develop for Linux, and bad programmers are those who develop for Windows. I struggle to believe someone who would make that argument has any significant experience in the world of programming. But I bet they think their pronouncements on Linux trump any old timer's. Eulampios who is posting here previously argued with me that it was right to misrepresent facts if doing so made Microsoft look worse.

        Operating Systems as religion and to Hell with any inconvenient people who remember LinuxJesus when he was just a man. How depressing.

    6. Vic

      > How would this thing get on the server in the first place?

      The "full disclosure" list doesn't seem to disclose that, but it does appear that the malware is a kernel module masquerading as a sound driver.

      If I'm right in that, then the infection vector must be a social-engineering attack to get an inexperienced sysad to install a driver for a new sound system he's bought. It's not clear how the modprobe occurs to load the kmod into the kernel, but these are the sort of things that tend to get noticed.

      Given the nature of the infection, I wouldn't expect to see it on any mainline servers. The actual infection vector is the only thing of interest here, and it appears to be targetted at hobby servers only.

      I'm not going to lose any sleep over this unless more worrying information comes to light.


      1. Tim99 Silver badge


        I agree. Hopefully we would only see this in the wild on a system that an amateur had exposed to the Internet, so that his buds can see their party photos.

        A sound driver on a web server, sigh - Beer, because you would have had to have a few before this looked like a good idea.

      2. YellowApple

        "it does appear that the malware is a kernel module masquerading as a sound driver."

        Which begs the question of who in their right mind would need a sound driver on a web server.

        No matter how secure an operating system is, not even the most invulnerable system can protect itself against administrator-level stupidity.

  2. Voland's right hand Silver badge

    niginx is not that "popular"

    To start with - nginx is not that popular. Now if this was squid, apache traffic server or pound...

    1. Bakunin

      Re: niginx is not that "popular"

      Nginx has been gaining a lot of popularity over the last couple of years as a load balancer in front of Apache. The usage statistics for Debian (only one distribution I know) show quit an uptake. But as the article states, that might be there target "market"

      (By the way, I know the Register was only quoting directly from the Securelist blog, but it's Debian Squeeze not Squeezy. Typo on their part I assume)

    2. diodesign (Written by Reg staff) Silver badge

      Re: niginx is not that "popular"

      Actually, the malware will inject iframe packets into any HTTP web server listening on port 80 - so it's not nginx specific :(

      I'ver amended the article.


      1. Anonymous Coward
        Anonymous Coward

        Re: niginx is not that "popular"

        Chris, could we have a paragraph or two on how it is supposed to infect the server in the first place, please? I think I'm not the only one puzzled by that omission.

  3. Tom 7

    security STARTUP CrowdStrike

    cant afford decent salespersons yet then?

    1. durandal

      Re: security STARTUP CrowdStrike

      They've clearly spent the cash on a half decent PR bot instead.

  4. K

    "intermediate programmer with no extensive kernel experience"

    Sounds like they are making this person out to be at the lower end of the "intermediate" skill set (amateur)...

    Bear in mind, he probably created one of the more advanced Linux based root kits publicly known - that sounds like somebody with pretty advanced skills to me!

  5. . 3

    It sounds like it's the method of modifying the TCP stack to inject some extra bytes and, perhaps more cleverly, knowing exactly when to do it that is the novel technique.

    Given there's no mention of how it gets planted on the server, the OS is pretty irrelevant. Perhaps the developer was just testing it out on some servers he already has access to that happen to all be running Debian. Having it spawning shells and writing temp files is pretty indicative of something not well polished.

    1. Dave Bell

      With all the logging tools and the like, that makes a sort of sense. Aren't there some standard cross-platform libraries involved in this TCP stuff? I know there is libcurl, but that is at a higher level than this seems to be. It does all suggest where the high-value targets in the Linux world are: not user computers but web servers.

      When will I get a kernel update because of this?

    2. Vic

      > the OS is pretty irrelevant.

      The OS is *extremely* relevant.

      This is a kernel module built for a specific kernel. You need just the right flavour of kernel, or the module will simply not work.


      1. . 3

        What I mean is this: He's written some clever code to modify the functionality of the TCP stack in such a way that it can tell when a new web page is on it's way out and modify it as it passes though without triggering anything watching. He might well be developing this on Linux (as let's be honest, it would be night on impossible trying to debug and test it under Windows), so having some real Linux servers to try it on would be invaluable.

        As there's no apparent mention of the method of installation, we can assume he has got root access to these machines by some other means and just gone in and done it manually. It's not a virus if there's no method of installing itself on other machines.

        Once the code is perfected, it can be ported to whatever OS is vulnerable to attack, yet still a worthwhile target.

        1. Vic

          > Once the code is perfected, it can be ported to whatever OS is vulnerable to attack

          Yes, but you've entirely missed the point I was making.

          If you can place your code on a box running kernel version 2.6.32-5, that attack *will not work* on an otherwise-identical OS running kernel 2.6.32-46. The module willl not be loaded, and the attack will fail.

          For this to be a widespread infection, the vector would need to install the kmod for every kernel fitted, and would need to monitor the filesystem on a regular basis in case any new kernels were installed. Each new installation would then need to be re-infected by downloading a new module built for that specific kernel.

          This is an interesting attack, to be sure, but it's incredibly unlikely to go anywhere.


          1. Anonymous Coward
            Anonymous Coward

            Or it could do like VMware Workstation/Player does

            And compile the module as part of the install process. Granted this requires some extra packages that will not be installed on every server, but the userspace component that does the original install could download what it needs, build the module, then clean up after itself.

            For bonus points, it could leave a slightly modified version of an existing startup script to verify the module is still in place. That way if the server's kernel is updated and the module doesn't load, the same build process can be initiated to build the module again for the updated kernel. Just like VMware does, except that it does it when you try to run VMware, rather than in the startup script. But there's no reason it couldn't be done there.

            1. Vic

              Re: Or it could do like VMware Workstation/Player does

              > the same build process can be initiated to build the module again for the updated kernel

              Yes, that's the dkms route.

              It requires dkms to be run on boot, it requires the kernel-dev stuff to be installed, it needs a compiler available.

              It's still a very long shot. I don't see this as a significant threat.


              1. Anonymous Coward
                Anonymous Coward

                Re: Or it could do like VMware Workstation/Player does

                It would only require dkms if you do it as part of the OS. The rootkit could have a userspace component hidden away that runs on boot to make sure the rootkit module is loaded. If it finds it is not, it would then download what it needs (kernel-dev stuff, etc.) to build itself, re-install the updated module, then delete everything as it would no longer be needed. It could do the download and build slowly over the course of a few hours so as to not draw attention to itself via network traffic, CPU usage or rapidly changing disk usage.

                1. Vic

                  Re: Or it could do like VMware Workstation/Player does

                  > It would only require dkms if you do it as part of the OS.

                  If it's not a part of the OS, it's not an infection...

                  > The rootkit could have a userspace component hidden away that runs on boot to make sure

                  > the rootkit module is loaded

                  That's exactly what dkms does. You can rewrite it with a different name if you really want to split hairs, but what you're talking about is exactly what dkms does.

                  > If it finds it is not, it would then download what it needs

                  So you've now got a malicious userland process running on a non-rootkitted kernel. *That* gets noticed.

                  > It could do the download and build slowly over the course of a few hours

                  For all that time, it has to do the sort of thing that will trip the intrusion detectors without the protection of a rootkit hiding its tracks. It then needs to install software without root privileges - requiring another privilege escalation vulnerability on the newly-installed kernel - and then load the module. This is not a viable infection route.


          2. . 3

            Ahh, I've got it now. I agree completely.

  6. dssf

    How it might be installed?

    Maybe it is a service tech, left alone when a distracting, deliberate call to the server cage comes in. Maybe the tech is evil, or is just paid to do the dirty deed. Maybe the attackers hit server cages that do not have cameras. Maybe they have few or no guards physically monitoring the service techs, who then sneak payload into a server via a flash drive or patch disc, then waits for reboot permission so nothing seems suspicous since the actual monitoring tech may be returned and unable to sift the files for illicit code among tens of thousands of lines of code.

    Just guessing. Am assuming the attackers gain PHYSICAL access, are granted live permission, and hold threatening power over the visiting tech rep. Again, just guessing.....

    1. Anonymous Coward

      Re: How it might be installed?

      Sounds like a great movie plot....

      Wait - I think it might have already been done (to death).

    2. PyLETS

      Re: How it might be installed?

      No system is secure against someone with physical access and a little determination. BIOS chips can be switched, and EvilMaid type attacks can be made against disk encryption if used to obtain the encryption key. This particular exploit wouldn't even need a reboot if the kernel module is dynamically loadable.

  7. Will Godfrey Silver badge

    We seem to have these OMG scares on a regular basis - often seems to coincide with 'another' vendor having problems.

    Note to self:- Beware Greeks bearing gifts.

  8. Skrynesaver


    Given the architecture, software and kernel version, is it possible to extrapolate to a targeted appliance ?

    Not that is can't be rebuilt, but it looks somewhat less indiscriminate than implied

  9. Agarax


    Guess they shouldn't have been using ... oh .. wait. Crap.

    1. Lockwood

      Re: Windows

      Yep. Linux is flawless.

  10. Phil Koenig

    I assume something like Tripwire or AIDE could prevent evil doers (or at least warn about them) trying to exploit your kernel with malware like this?

  11. PaulWizard

    A Russia-based attacker is likely

    Aren't Kaspersky Russian?

    1. Anonymous Coward
      Anonymous Coward

      Re: A Russia-based attacker is likely

      So? Trying to be funny or something?

  12. Khaptain Silver badge
    IT Angle

    Infallible does not exist

    An infallible system is one which does not exist. Root Accounts can be obtained by many different means and none are as good as Human Error, be it logical or intellectual.

    Anyone that believes that system A or Distro B is unhackable looks like a fool everytime a new hack is discovered.

    Hackers have time on their hands and lots of it, and there are lots of them. Eventually they will and do find errors, backdoors or will even socially engineer a PFY.

    Then you have to prevent "Inside Jobs", "industrial hacking", ex-employee that still hold hidden passwords, the list goes on and on......

    It's laughable to see those that are "shocked" to learn that someone hacked Linux, it is definately secure but definately not un-hackable........


    1. Ole Juul

      Re: Infallible does not exist

      It's laughable to see those that are "shocked" to learn that someone hacked Linux, it is definately secure but definately not un-hackable........

      So who's shocked? What's your point? The fact that it is possible to compromise any system is not being discussed here. The question is the means.

      By the way, it looks like your spell checker was compromised. ;)

  13. Blarkon

    Web Applications are the vector

    Incorrectly configured web applications are a vector. Just because you're managing a Linux box doesn't mean that the developers who coded the web applications on the server haven't done something stupid. Those web applications don't come from repositories - they are likely developed either in house, or your organization has paid someone to develop them.

    1. h4rm0ny

      Re: Web Applications are the vector

      True. But there would still need to be a flaw in the server OS to allow a web application to escalate privilege and install this. That said, such flaws do exist. But it's worth being clear that this would be necessary. You can't install something like this just because you have a hosting account on that box.

      1. eulampios

        Re: Web Applications are the vector

        That said, such flaws do exist.

        On a an up-to-date system? If so, can you give us at least one such flaw we could exploit . Thanks

        1. h4rm0ny

          Re: Web Applications are the vector

          "On a an up-to-date system? If so, can you give us at least one such flaw we could exploit . Thanks"

          You're asking me for a zero-day exploit that you can exploit? Uh, no.

          What I wrote was that such flaws exist. I meant that they occur. You are the one that shifted the argument to my personally knowing of ones in advance of the people who patch and fix these things which is an unreasonable shift. I'm just pointing out that they occur. If you argue that they don't then you're ignorant and you're position is based on faith rather than study. Here is an example of one: Link It's pretty irrelevant to post it except for you to show that these can and do happen on Linux seeing as you seem so doubtful.

          There was a privilege escalation in an NVIDIA driver last month as well. But I daresay you would try to shift the argument there as well, saying that it's not actually part of the Linux kernel. Despite it's presence on huge numbers of Linux PCs. The reason you would think it valid to shift it is because your motivation is to show that "Linux" (as if it were a person) is not at fault. Whereas my motivation is really just real world security and to show that a Linux system can be hacked.

          1. eulampios


            IMHO, there's not too much harmony in your allegations. A statement containing the existential quantifier must be demonstrated with a valid example, in our case with an exploit. Otherwise, the predicate is not true. What you meant is not what you wrote. Please use "were known to exists" and/or "are likely to be found" and so on, instead.

            It's pretty pretentious on you side, since you seem to not see my on the up-to-date system clause.

            Yes, I have seen and played with a couple of Linux priv. escalation exploits. Some of exploits have resulted from the freshly added code and did not linger in the kernel for too long, BTW

            Statistically speaking, the risk is pretty low, yet not zero. The risk lower than that to be found patched by MS in their kernel. Moreover, this risk gets diluted substantially due to the following

            1) oftentimes need more vulns (outside) of kernel to be able to use them, like arbitrary code executions (desirably, remotely)

            2) might not work across all the multitudinous branches and (up-to-date) versions

            3) (those that we known) are found fast, can't recall an exploit to be maliciously used before being detected and patched

            4) patched pretty fast

            The one talked about in the article is pretty foggy. We don't know what are we dealing with, whether it an exploit, blunder or an intent for publicity/FUD. The vector is not known if any. And this is FUD until proved otherwise, imo.

  14. David Hicks

    Infection vector?

    That's the more interesting part to me. Do we have a malicious employee? A remote exploit and then privilege escalation? Just some weak passwords?

    The only time bad things happened to my public facing linux machine were during the time when it really shouldn't have been public facing and had horribly weak passwords. I was still half-way through adding kernel support for the platform, the root password was 'root' and root SSH access was allowed. Not that that's how they got in, first they gained access to the 'dave' user (password 'dave') and then spent quite some time guessing at root.

    The eventual attempt at using their new-found power was full-on retarded though - they created a ramdisk (on a machine with 32Mb of RAM) and then tried to run a shoutcast binary, compiled for x86, on an experimental ARM box....

    1. eulampios

      Re: Infection vector?

      Interesting story. My home server got 2 users besides me I disabled their ssh logins (no root, if it were I'd disable it of course). My user name is not very uncommon, password is reaaallly long, however, I only get about 0 or one out of many thousands ssh probes every week that get the username even close.

  15. Anonymous Coward
    Anonymous Coward

    Maybe its time... start thinking of Linux antivirus software?

    1. h4rm0ny

      Re: Maybe its time...

      Perhaps. But this is malware for a server. Servers are typically run by people who are more cautious, keep their systems patched and up to date, and are less likely to run the sort of risks that allow malware to be installed in the first place. (Well, except for Eadon who seems to think use of Linux immediately means you can take your brain off the hook and sit back).

      So this is a lot less likely to propagate wildly than something found on, say, Windows. Not saying there's no reason for anti-malware software on Linux. It actually exists. Just pointing out that this is a different scenario to most malware.

      1. Chemist

        Re: Maybe its time...

        Genuine non-trolling query

        I've used Linux for years without any anti-virus, as far as I know there are so few threats and the existing AV programs mostly seem to look for Windows malware that might be passing through. It's summed up in these quotes from the Wikipedia page :

        "There are a number of anti-virus applications available which will run under the Linux operating system. Most of these applications are looking for exploits which could affect users of Microsoft Windows."

        "The following is a partial list of known Linux malware. However, few if any are in the wild, and most have been rendered obsolete by Linux updates or were never a threat. Known malware is not the only or even the most important threat: new malware or attacks directed to specific sites can use vulnerabilities previously unknown to the community or unused by malware."

        So far I've relied on regular updates, good firewalls, careful browsing on a limited account, separate account for banking, VERY hard passwords for secure stuff like banking and SSH, and rigid adherence to good practice. (yes I often get e-mailed Windows malware or phishing tricks)

        The questions - is this enough - anyone know how effective the current AV products are ? - is this a non-issue ?

        1. dogged

          Re: Maybe its time...

          Cost/Benefit analysis time, I guess.

          If you back up regularly and keep your archive, configure your firewall well, pay attention to safety alerts and don't go into the murkier parts of the web, you're probably fine. As indeed, you would be with an OSX or Windows box under those circumstances.

          If your data is very valuable, the cost of antivirus may be negligible compared to possible losses. If it's not, no biggie. Sadly, you're the only one who can do the sums here because nobody else knows the figures.

        2. h4rm0ny

          Re: Maybe its time...

          "The questions - is this enough - anyone know how effective the current AV products are ? - is this a non-issue ?"

          If you do all that you say you do, then the real question would be: is there anything more you can do. To which I'd say no, not really. About the only thing you could do more than you say you're doing is to monitor all the software you have installed yourself and try to patch it faster than your distribution actually does. Which is a nonsense task in practice. You might want to look at SE Linux depending on what your boxes actually do. And you would might want to install additional security tools like Suhosin if you're running a webserver. Basically, the only thing you haven't mentioned that you are doing is proactively checking to see if you have been compromised. E.g. there are tools that will monitor your system for unexpected changes. You could look into that.

          But really, if you're doing everything you say you are and you're running Linux, you're going to be pretty safe. I don't use any sort of anti-virus on my own boxes. One of my clients has some of that pro-active monitoring software I talked about but I'm not overly-familiar with it. I could look into it if you're interested, but it's way overkill for your box if you're just a human being and not a company or intelligence agency.

          1. Chemist

            Re: Maybe its time...

            Thanks for that.

            In reality I'm not too worried - I run a webserver on the internal network but the only external open port is a non-standard one for SSHD which as I mentioned has a password from hell *and a very non-standard username as the only valid account. The server running SSHD is firewalled, the NAT router is firewalled and all ports below 1024 are filtered at my ISP. I'm assuming that the major risk is e-mail attachments and given that I'm VERY suspicious and have trained my wife to be the same I'm fairly sanguine.

            I agree I could try tripwire or some such or apparmor.

            I really wanted to open up any discussion around Linux security and see if there was anything I'd missed.

            *The password from hell is NOT written down, is 20 digits long something not like "bcGbf54TTt32dfcm2n1f" and generated on the fly by a little c program from a passphrase that I can remember. I use the same method, with different passphrases for all my serious passwords

          2. Phil Koenig

            Re: Maybe its time...

            It's not necessarily a matter of guessing login credentials, it's a matter of buggy software that allows itself to be exploited and give up access whether or not the attacker has valid login credentials.

        3. ElReg!comments!Pierre

          Re: Maybe its time... (genuine non-trolling answer)

          This is a SERVER-specific malware that -for now- peddles MSWindows-targetted crap. If you are not operating a webserver this is a complete non-issue for you. If you are administrating Debian-based web servers (as I am), AND you suspect unauthorized physical access then you might want to check your systems.

          As for me I'll quitetly drift into my dreams tonight with the reassuring certitude that my systems are reasonnably safe; much safer than the competition's. But to each it's own vuln, as MS salespersons say ;-)

  16. Christian Berger

    Just to make it clear, there is are primitive remedies

    a) Have a monolithic kernel without module support. This is easily done on virtual servers since all the hardware is precisely the same.

    b) Run your operating system from a read-only disk. This can also be done for mass hosters easily. It is a bit more tricky for smaller installations. But this keeps the problem from surviving a reboot.

    Sure both require effort and may not be doable, but they work and can be implemented by mass-hosters fairly easily. I would be surprised of some of those wouldn't already do it for years.

This topic is closed for new posts.

Other stories you might like