Coffeehouse Thread

12 posts

Mozilla is a virus

Back to Forum: Coffeehouse
  • User profile image
    Manip

    Infected binary or source code files aren't anything new. And sometimes they are found on public servers. Mozilla.org is the latest example.

    Korean distributives for mozilla and thunderbird for linux turned out to be infected - mozilla-installer-bin from mozilla-1.7.6.ko-KR.linux-i686.installer.tar.gz and mozilla-xremote-client from thunderbird-1.0.2.tar.gz were infected with Virus.Linux.RST.b

    This virus searches for executable ELF files in the current and /bin directories and infects them. When infecting files, it writes itself to the middle of the file, at the end of a section of code, which pushes the other sections lower down. It also contains a backdoor, which downloads scripts from another site, and executes them, using a standard shell.

    The infected files have now been removed, but it took some time. And this isn't the first time that infected binary or source code files have been placed on public servers. Yet another example of why you should have an up to date antivirus solution, and scan EVERYTHING you download, without exception.

    http://www.viruslist.com/en/weblog?calendar=2005-09

    PS: My profile time isn't working. The thread says it was posted at 9:47 but it is 14:47 here in the UK.

    Disclaimer: This thread has slightly more purpose than this thread here


  • User profile image
    Sven Groot

    It also provides a good argument for the signing of executables that MS always does. At least there you know that the file hasn't been tampered with.

    Of course, that doesn't mean it's clean; the file could've been infected from the beginning, and the infected copy signed. But that's a whole lot less likely to happen than it getting effected when distributing it to various servers.

  • User profile image
    Cybermagell​an

    Nice....

    Sometimes (I've had it before) you get a malformed compile (broken binary) and it apears to the computer as a virus. However knowing how Asa felt about Linux on the desktop who knows they may have purposly made it that way (joking).

  • User profile image
    SvendTofte

    This site is to MS as Slashdot is to Linux. Did you actually try and read the link you posted? Is MS responsible if idiots downloads patches from p2p, and find that they get infected? The Korean server is not an affiliated Mozilla site, it's just any old fan site. Yawn.

  • User profile image
    Manip

    SvendTofte wrote:
    This site is to MS as Slashdot is to Linux. Did you actually try and read the link you posted? Is MS responsible if idiots downloads patches from p2p, and find that they get infected? The Korean server is not an affiliated Mozilla site, it's just any old fan site. Yawn.


    Don't shoot the messenger.

  • User profile image
    Larry​Osterman

    SvendTofte wrote:
    This site is to MS as Slashdot is to Linux. Did you actually try and read the link you posted? Is MS responsible if idiots downloads patches from p2p, and find that they get infected? The Korean server is not an affiliated Mozilla site, it's just any old fan site. Yawn.


    Svend, if the binary had been signed, then it would have been irrelevant, because the signature verification would have failed and nobody could be infected.

    People seem to believe that just because they run *nix (or OSX) that they are somehow immune to viruses, they're not.

    Sloppy distribution processes are what's at fault here - there's no way that a non affiliated site should be allowed to host non signed binaries, and the OS should warn you and give you the tools to determine that the binary in question was not that which was produced by the official author.

  • User profile image
    Maurits

    LarryOsterman wrote:

    Svend, if the binary had been signed, then it would have been irrelevant


    I thought Mozilla did sign their binaries. (Downloads latest firefox setup.exe...) Yup, it's signed.  The code signing certificate was issued 12/24/2004, so they have been signing binaries since at least that time.

    The Linux .tar.gz's also have .asc's sitting right next to them (the Linux equivalent of a signed executable)

  • User profile image
    Larry​Osterman

    Maurits wrote:
    LarryOsterman wrote:
    Svend, if the binary had been signed, then it would have been irrelevant


    I thought Mozilla did sign their binaries. (Downloads latest firefox setup.exe...) Yup, it's signed.  The code signing certificate was issued 12/24/2004, so they have been signing binaries since at least that time.

    The Linux .tar.gz's also have .asc's sitting right next to them (the Linux equivalent of a signed executable)


    They do for Windows platforms (after Microsoft's Peter Torr shamed them into doing it).
     
    For *nix, does the infrastructure force the inspection of the ASCs?  In other words, if someone doesn't manually verify the ASC file, what happens?

    If the OS doesn't say "hey, the signature on this file isn't the right file" then there's a problem.

  • User profile image
    Detroit Muscle

    LarryOsterman wrote:
    For *nix, does the infrastructure force the inspection of the ASCs?  In other words, if someone doesn't manually verify the ASC file, what happens?

    If the OS doesn't say "hey, the signature on this file isn't the right file" then there's a problem.


    The RPM package format allows signing. And yes, RPM will warn you if the signature doesn't match the file on install.

  • User profile image
    Larry​Osterman

    Detroit Muscle wrote:
    LarryOsterman wrote: For *nix, does the infrastructure force the inspection of the ASCs?  In other words, if someone doesn't manually verify the ASC file, what happens?

    If the OS doesn't say "hey, the signature on this file isn't the right file" then there's a problem.


    The RPM package format allows signing. And yes, RPM will warn you if the signature doesn't match the file on install.


    Cool - but these weren't RPMs then?  Otherwise I don't see why it was an issue at all.

  • User profile image
    Maurits

    LarryOsterman wrote:

    For *nix, does the infrastructure force the inspection of the ASCs?


    Nope - *nix gives you enough rope to hang yourself with.  For .tar.gz's, anyway.  RPMs are another matter.

    LarryOsterman wrote:

    In other words, if someone doesn't manually verify the ASC file, what happens?


    Whatever the user types.  Usually the following recipe:

    wget http://www.example.com/foo.tar.gz

    # BEGIN OPTIONAL PART

    # download the signature
    wget http://www.example.com/foo.tar.gz.asc

    # download vendor public key - get this from a reliable source
    # note this only needs to be done once per vendor
    # some vendors expire their keys once a year
    wget http://www.example.com/KEY

    # say "I trust that this key is what it says it is"
    # also only needs to be done once per vendor
    gpg --import KEY

    # verify that file is what the signature says it is
    # this also says who signed it
    gpg --verify foo.tar.gz.asc

    # END OPTIONAL PART

    tar xzvf foo.tar.gz
    cd foo
    make
    make test
    su -c "make install"

    If the optional stuff is skipped, the installation takes place without trust-verification.

    LarryOsterman wrote:

    If the OS doesn't say "hey, the signature on this file isn't the right file" then there's a problem.


    It's not the epitome of usability, that's for sure.

  • User profile image
    Detroit Muscle

    If you want to compile from source and still want automatic signature checking of the downloaded source package, there's always *.src.rpm.

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.