<epigraph>
  <attribution>Confucius</attribution>
  <simpara>
    The superior man understands what is right;
    the inferior man understands what will sell.
  </simpara>
</epigraph>

<simpara>
  On <link linkend="credits">Silvio Cesare</link>'s site used to be a
  text file named <filename>elf-pv.txt</filename>.
  Complete title is
  <quote>Unix <acronym>ELF</acronym> Parasites And Virus</quote>,
  dated October 1998.
  It gives some background and then describes the gap between code
  and data segment, as illustrated in <xref linkend="segment.padding"/>.
  At the end of the text is an uuencoded file
  <filename>unix-linux-pv-src.tgz</filename> containing sources.
  The package is also available as plain
  <filename>vit-src.tgz</filename>.
  <footnoteref linkend="note.silvio.cesare"/>
</simpara>
<blockquote>
  <simpara>
    [&hellip;] The name of this virus by curiosity was given by the
    people at F-Prot &note.fprot; who noticed the virus created a
    temp file using the letters VIT.
  </simpara>
</blockquote>
<simpara>
  In another text he calls the concept
  <quote>the text segment padding virus (padding infection)</quote>.
  Anyway, the code is hard to read as he started development with 
  a piece of plain C and applied several transformations.
  It seems that he released the stuff the very second it produced results.
</simpara>

<sect2>
  <title>Three years later</title>

  <simpara>
    <quote>Remote Shell Trojan: Threat, Origin and Solution</quote>
    &note.securiteam.5MP022K5GE; is dated 10/9/2001.
  </simpara>
  <simpara>
    Perhaps they had to cut out all interesting details to protect
    their source. But what I read on that page makes little sense to me.
    Supposedly script kiddies &note.jargon.script.kiddies; got hold of
    experimental back door code and planted it on sites they had
    access to. No names, dates, sites or legal consequences given.
    No details on the method used by intruders to gain access.
  </simpara>

  <blockquote>
    <para>
      [&hellip;] From this point, the virus seemed to spread in
      the wild.
    </para>
  </blockquote>

  <simpara>
    Well, how does it spread? There is no reference to a root
    exploit, either local or remote. It is explained that if
    root starts an infected program owned by another user, a virus
    can pollute the whole system. But how many people really do this?
    <footnote>
      <simpara>A poll on &url.slashdot; might give answer.</simpara>
    </footnote>
    And the question on how the virus spreads to other machines remains.
  </simpara>
  <simpara
    >It is plausible that script kiddies copy root kits
    (including viral back doors) wholesale to cracked machines.
    It is possible to combine a remote exploit with such a virus
    to build a persistent worm, though creative work of this
    extent is by definition out of reach for script kiddies.
    But in both cases the problem is the used exploit,
    not the qualities of the installed back door.
  </simpara>
  <simpara
    >Anyway, the concluding remark is strange:
    <footnote><simpara
      >We should make another poll on &url.slashdot; about how many
      people used the detector. It must have been all of them. Or is
      there another explanation that the predicted catastrophe did not
      occur?
    </simpara></footnote>
  </simpara>
  <blockquote>
    <para
      >[&hellip;] Again, it is strongly recommend that anybody running
      Linux run the detector to see if their system is infected.
      Even if they do not expect anything, they can always optionally
      immunize their system. This is the only way we can fight the
      further spread of this virus.
    </para>
  </blockquote>
  <simpara
    >Attached to the article is Perl and C code that detects
    and vaccinates against <acronym>RST</acronym>. Though I never
    encountered the culprit, seeing the antidote makes me sure it
    is a variation of Silvio Cesare's concept.
  </simpara>
  <simpara
    >I am certain that <xref linkend="scanners"/> would detect
    <acronym>RST</acronym>. If I had a copy (add collecting to my
    list of incompetencies). And that a deactivated infection with
    <xref linkend="segment.padding"/> has the same effect as the
    immunizer on that site. 
  </simpara>
  <simpara>
    Anyway, the code checks whether the entry point is exactly
    <constant>4096</constant> from the end of the code segment.
    If not, the executable is considered immune. This gets fooled
    by both the simple alignment in
    <xref linkend="target.copy.and.infect.1"/>
    (which makes the distance less than <constant>4096</constant>)
    and the improvements made in &yref.entry.point;.
  </simpara>

  <programlisting><inlinemediaobject><imageobject><imagedata
    format="linespecific"
    fileref="../src/rst/01.inc"
  /></imageobject></inlinemediaobject></programlisting>

  <simpara>
    The code also tries to clean infected executables by restoring
    the entry point. I don't trust that part, however:
  </simpara>

  <programlisting><inlinemediaobject><imageobject><imagedata
    format="linespecific"
    fileref="../src/rst/02.inc"
  /></imageobject></inlinemediaobject></programlisting>

  <simpara>
    I can't see any attempt to verify the retrieved address.
    Silvio Cesare's classic pieces stored the original entry point
    at a non-intuitive address in the middle of infective code.
  </simpara>

</sect2>
<sect2>
  <title>The lighter side</title>

  <simpara>
    Above code contains everything to build an infector.
    Obviously it is written from reverse angle.
    Posted on a HTML page without <sgmltag>&lt;pre&gt;</sgmltag> or
    <sgmltag>&lt;tt&gt;</sgmltag> tags.
    And there are no references to preceding works and authors.
    But these are all inevitable constraints of trojan source code
    (term invented by me, right now). By delivering a good show
    it is possible to trick unsuspicious high-bandwidth sites
    into hosting educational material of the guild.
  </simpara>

</sect2>
<sect2>
  <title>Another three months later</title>

  <simpara>
   <quote>New Linux Backdoor Virus Gains Smarts</quote>
    &note.newsbytes.02.173408; is dated 05 Jan 2002.
  </simpara>

  <simpara>
    What does the title mean? I feel very illiterate.
    Does it really fit this text?
  </simpara>
  <blockquote>
    <para>
      [&hellip;]
      To date there have been "limited" reports of the new
      <acronym>RST</acronym> variant in the wild, according to
      Eschelbeck. To replicate, the virus requires users to run an
      infected program from an account with "root" permissions.
      Upon execution, the infected program will attempt to spread the
      virus to all <acronym>ELF</acronym> files on the local system,
      he said.
    </para>
  </blockquote>
  <simpara>
    If the virus cannot gain root on it's own devices,
    left alone reach other machines, how does it propagate at all?
    If this is just a fancy kind of back door then it must have been
    planted after a successful attack. What type of attack?
    What vulnerability? On what distributions?
    Are there updates available?
    What does CERT &note.cert; say about it?
  </simpara>
  <blockquote>
    <para>
      [&hellip;]
      However, Russell said it would be "dead simple" to attach the
      virus to a useful program, such as a tool that exploits a security
      hole, and beguile some users into running it.
    </para>
  </blockquote>
  <simpara>
    The first sentence is funny. Do they really say that an
    exploit is a useful program? Or does this just mean that
    <quote>Remote Shell Trojan</quote> is not a trojan according
    to <link linkend="what.exactly.is.a.virus">my definition</link>?
  </simpara>
  <simpara>
    To me it summarizes like this: On some cracked machines 
    a new kind of back door was found. Period.
  </simpara>

</sect2>
<sect2>
  <title>The serious side</title>

  <para>
    There is a lot of documentation in the net. 
    For example the Security-HOWTO &note.HOWTO.security;
    tells this in section
    <quote>10. What To Do During and After a Breakin</quote>:
    &note.HOWTO.security.10;

    <blockquote>
      <para>
	[&hellip;]
	Re-installation should be considered mandatory upon an
	intruder obtaining root access. 
	[&hellip;]
      </para>
    </blockquote>
  </para>

  <para>
    There is a Unix-FAQ &note.faq.unix;
    which explains trivia like
    <quote>What's wrong with having '.' in your $PATH?</quote>
    &note.faq.unix.p2s13;
    More specific information is the FAQ of comp.security.misc,
    comp.security.unix and related groups.
    <footnote
      ><simplelist>
        <member>&url.faq.computer.security;</member>
        <member>&url.computer.security.faqs;</member>
      </simplelist
    ></footnote>
    Another interesting piece is <quote>Steps for Recovering from a
      UNIX or NT System Compromise</quote>. &note.cert.compromise;
    Finally we have the suicide methods FAQ. &note.faq.suicide.methods;
  </para>

  <simpara>
    News sites seem to avoid the topic of prevention like the plague.
    For some yet unknown reason readers are given no hint to educate
    themselves, or question the sanity of day-to-day behavior.
    Security incidences are described as act of evil forces beyond
    mortal control. 
    Instead I detect a strange appeal for magic tools that can
    cure disease after contagion
    <footnote><simpara>
      The second article links to &url.qualys;,
      which even seems to sell them.
    </simpara></footnote>
  </simpara>
  <simpara>
    There might come the time of a completely brain washed user
    base taking incredible risks every day. This could be a major
    opportunity for the folks coding trojans.
    And perhaps, if dumbed down customers exert enough pressure
    on vendors, the security concepts implemented today might be
    rendered inactive on a default installation. &note.newsforge.181122;
  </simpara>
</sect2>
<sect2 id="another.theory" xreflabel="Another theory">
  <title>Another theory</title>

  <simpara>
    <quote>Rare Linux virus on the loose</quote> &note.vnunet.1127965;
    is dated 03-01-2002.
  </simpara>

  <blockquote>
    <para>
      [&hellip;] The researchers warned that the culprit carrying the
      virus is likely to be "some exploit being passed around,
      possibly a Secure Shell one". Linux users are advised not to
      run exploits from unknown sources. [&hellip;]
    </para>
  </blockquote>

  <simpara>
    The article does not back this up with facts.
    But the idea itself is interesting.
  </simpara>
  <simpara>
    One of the strongest obstacles to virus spread is the distribution
    concept of Linux. Typical installation method is a set of CDs
    from a single vendor. Probably a lot of people don't buy the
    disks but copy them. However, it is quite difficult to infect
    ISO-9660 images. Even more if the CDs are copied on the fly
    using two drives.
  </simpara>
  <simpara>
    Most other software is downloaded from a specific site.
    Either a central repository like
    <ulink url="&http.sourceforge;">&http.sourceforge;</ulink>
    or registered on a place like
    <ulink url="&http.freshmeat;">&http.freshmeat;</ulink>.
    Should such a download site ever get infected by a virus
    there is just a single place to shut down.
  </simpara>
  <simpara>
    Some sites are mirrored to share bandwidth demands.
    But most mirrors are set up to automatically take over changes
    on a daily or weekly base.
    So I guess that all <quote>official</quote> sources of
    infected software will dry up fast.
    Something similar actually happened.
    See the story of the irssi 0.8.4 back door. &note.irssi.backdoor;
  </simpara>
  <simpara>
    On the other hand 0-day exploits are traded in secrecy.
    From one hand to the other. Without authoritative origin.
    And little incentive to raise public attention.
    But then I doubt that script kiddies 
    <footnoteref linkend="note.jargon.script.kiddies"/>
    called in security consultants after infecting their own machines.
    It might be possible that white hat administrators tested such
    an exploit on their own production machines.
    I agree with the citation that this is a stupid thing to do.
    But in that case the administrators would still have the original
    binary they executed. Which would clarify the issue beyond doubt.
    To me <quote>is likely to be</quote> means that someone might
    have installed the virus without knowing it, but on a machine already
    rooted. Big deal.
  </simpara>

</sect2>
<sect2 id="ids" xreflabel="Intrusion detection systems">
  <title><acronym>Intrusion detection systems</acronym></title>

  <simpara>
    Most package systems maintain some kind of verification database
    including intended file owner, file permissions, file size and a
    checksum. This facility can be used to check for modifications to
    system files. The platform specific chapter
    &yref.verifying.installed.packages; shows actual examples.
    <quote>Rute User's Tutorial and Exposition</quote>
    &note.rute.packages; includes a nice task based comparison of
    <citerefentry>
      <refentrytitle>rpm</refentrytitle>
      <manvolnum>1</manvolnum>
    </citerefentry> and
    <citerefentry>
      <refentrytitle>dpkg</refentrytitle>
      <manvolnum>1</manvolnum>
    </citerefentry>/<citerefentry>
      <refentrytitle>debsums</refentrytitle>
      <manvolnum>1</manvolnum>
    </citerefentry>.
    Both package formats provide checksums based on
    <citerefentry>
      <refentrytitle>md5sum</refentrytitle>
      <manvolnum>1</manvolnum>
    </citerefentry>.
    Feature-wise the only difference between them is the fact that
    checksums are optional for
    <citerefentry>
      <refentrytitle>deb</refentrytitle>
      <manvolnum>5</manvolnum>
    </citerefentry>. A typical installation of Debian includes a lot
    packages without checksums.
  </simpara>

  <simpara>
    A possible counter attack is to patch the database after
    infection. This is distribution dependent and requires root
    permissions. But it can be done. If you are serious about this
    issue you should use a real <acronym>IDS</acronym> and store the
    checksums offline.
    There is a FAQ &note.sans.org.ids; hosted by SANS Institute.
    &note.sans.org; And a brief introduction to products is
    <quote>Talisker's Intrusion Detection System List</quote>.
    &note.networkintrusion; tripwire &note.tripwire; has achieved a
    big name, but there is other free software: snort, &note.snort;
    aide, &note.aide; and lids. &note.lids;
  </simpara>

  <simpara>
    A poor man's approach to this problem is to use the checksums
    as they are stored in in the package files, e.g. on the
    installation CDs.
    Anyway, the real challenge for every kind of system verification is
    to limit the amount of false positives. Package based checksums
    are very bad in this regard, since they compare files with the
    initial state after installation. But then configuration files need
    to be modified to get the system running, so they will always
    be reported as messed up.
    A quick fix is to ignore a large number of files, either because
    their name matches a pattern or an exclusion list, or because
    they are marked as being somehow special in the package database.
    But then some of these files, e.g. <filename>/etc/crontab</filename>,
    can be used to install back doors. Still worse, putting a new file
    into a directory like <filename>/etc/cron.d</filename> or
    <filename>/etc/rc2.d</filename> can serve the same purpose.
    <footnote><simpara
      ><application>pkgchk</application> on SunOS features option
      <option>-x</option> that is described as
      <quote
        >Search exclusive directories, looking for files
        which exist that are not in the installation software
	database or the indicated pkgmap file.</quote>
      I did not get it working.
    </simpara></footnote>
    Real <acronym>IDS</acronym> handle these problems by taking
    snapshots of the system and doing smarter tests.
  </simpara>

  <simpara>
    Another possible attack is to hide the original (uninfected)
    executable on the file system, and patch the kernel via an
    inserted module to fake calculation of the checksum. A common
    name for this concept is <quote>Loadable Kernel Module (LKM)
    Rootkits</quote>. &note.samhna.lmk;
    And if the kernel is compiled without module-support,
    there is still direct access to <filename>/dev/kmem</filename>
    to install a kernel-patch. &note.phrack.58.58.7;
    But that's not the end of the story &hellip; &note.sealing.the.kernel;
    &note.capability.bounding;
  </simpara>

  <simpara>
    Really reliable checksum verification requires a clean boot
    (e.g. from CD-ROM) and comparison with a clean snapshot stored
    offline (e.g. written to CD). On this road lies madness.
  </simpara>

</sect2>
