Re: Compilers make a system less secure?

[jared r r spiegel <jrrs_(_at_)_ice-nine_(_dot_)_org>]

On Tue, May 02, 2006 at 09:49:07PM +0100, Constantine A. Murenin wrote:
> On 02/05/06, jared r r spiegel <jrrs_(_at_)_ice-nine_(_dot_)_org> wrote:
> >
> >  if we didn't have that little PIII/450 sitting next to the
> >  machine now, for the purposes of bringing live, getting
> >  patches onto, making .tgzs, and then copying them over to
> >  untar onto host B, what bob beck criticized about would be
> >  entirely accurate about me.
> 
> One thing I didn't follow in this story is why did this 'virus' change
> the host key?
> It's not like you can't use the old key with the new sshd install, is it?

  it installed its own replacement sshd and host_*_keys.  had its
  own config dir.  didn't overwrite anything in /etc/ssh .. was
  either /etc/ssh2 or /usr/local/etc/ssh2....  i don't
  believe we found the src for it lying around, but here's the
  stuff i did find and save from it:

  ( the sshd is gone, might've been some symlinks i whacked too )

---
$ find r00*
r00t3d
r00t3d/ssh-askpass
r00t3d/ssh-askpass.old
r00t3d/ssh-add.old
r00t3d/ssh-add
r00t3d/ssh-agent.old
r00t3d/ssh-add2
r00t3d/ssh-agent
r00t3d/ssh-chrootmgr
r00t3d/ssh-agent2
r00t3d/ssh-dummy-shell
r00t3d/ssh-keygen
r00t3d/ssh-keygen.old
r00t3d/ssh-keygen2
r00t3d/ssh-probe
r00t3d/ssh-probe.old
r00t3d/ssh-probe2
r00t3d/ssh-pubkeymgr
r00t3d/ssh-signer
r00t3d/ssh-signer.old
r00t3d/ssh-signer2
r00t3d-2/ssh2
r00t3d-2/ssh2/hostkey.pub
r00t3d-2/ssh2/hostkey
r00t3d-2/ssh2/ssh_dummy_shell.out
r00t3d-2/ssh2/random_seed
r00t3d-2/ssh2/ssh2_config
r00t3d-2/ssh2/sshd2_config
r00t3d-man/ssh2_config.5
r00t3d-man/ssh2.1
---

  commandline utils ( eg: ssh-keygen ) were also suid root.

> Another thing is trusting the updated hostkey. Imagine you are a
> sysadmin at a university. Do you keep the old hostkey when you
> reinstall the system on a specific host?

  in this case, no, :).  the "host B" has since been replaced/installed
  afresh.

  in situations of non-compromise, regarding the question of
  hostkey-retention after reinstall/etc, i usually let the new
  one ride and just give anyone appropriate a heads-up.

  i've also had it in my mind to finish up a setup using SSHFP records
  and a reasonably noncomplicated infrastructure to allow various
  users to update the hostkeys they're responsible for ( eg
  in a VPN or an environment where a team of persons have 
  individual primary maintainership of a variety of hosts ).  that's
  wicked OT tho.

> What about when you upgrade a
> Sun workstation, but keep the old hostname? How am I as a student may
> know if the new hostkey is legitimate? Good thing if I have an entry
> of another Sun workstation in the destination network in my
> .ssh/known_hosts, to which I could ssh and see if the host in question
> shows the same signature 'locally', but what if I don't?

  would using a global /etc/ssh/ssh_known_hosts file (which was
  under your jurisdiction) help solve that?  i haven't ever used
  a global one so don't know first-hand if that's its purpose.
  certainly wouldn't help if the student accessed the newly-upg'd
  workstation from their own desktop or whatever; but if they
  hit it from some other lab workstation (or etc) instead of
  from their personal machine...

-- 

  jared

[ openbsd 3.9-current GENERIC ( mar 15 ) // i386 ]