Slashdot Mirror


New FreeBSD, NetBSD Security Advisories

Dan writes "FreeBSD has formally announced a security advisory entitled "OpenSSH buffer management error" for the now famous OpenSSH advisory (OpenSSH has released a new version 3.7.1 to address this issue). NetBSD has issued a similar advisory and fix for this issue. NetBSD has released two additional security advisories entitled "Kernel memory disclosure via ibcs2" and "Insufficient argument checking in sysctl(2)"."

13 of 71 comments (clear)

  1. Patches vs. Fixes by Dancin_Santa · · Score: 5, Interesting

    If you ever take a look at the patched code for one of these security advisories, you mainly see some special case code stuck in there to patch up the problem. You never see a reconsideration of the problem. I wonder how long it takes to go from a release version through patch after patch until a piece of code is just old and crufty and in need of wholesale replacement.

    1. Re:Patches vs. Fixes by Horny+Smurf · · Score: 4, Informative

      in this case, the problem was a bug rather than a design issue, so a 3-line code change is appropriate. I do agree that there is a lot of "special case" "fixes" that try to hide fundamental problems.

    2. Re:Patches vs. Fixes by Anonymous Coward · · Score: 4, Insightful

      If you ever take a look at the patched code for one of these security advisories, you mainly see some special case code stuck in there to patch up the problem.

      If you ever take a look at the actual *problem*, you'll find that hey are usually just buffer overflows or other unchecked data, in which case 'some special case code' is the only appropriate course of action.

  2. I'll tell you what's REAL BSD news by Anonymous Coward · · Score: 5, Funny

    The first comment on a BSD story wasn't a BSD troll, now that my freinds is news for nerds, stuff that matters.

  3. OS X by Zelet · · Score: 4, Interesting

    Does this affect OS X's implementation of SSHD? So far Apple has not released a patch.

    --
    ...And when they came for me, there was no one left to speak out for me." - Martin Niemoeller (1892-1984)
    1. Re:OS X by dthable · · Score: 5, Informative
      I'm running 10.2.6 and I have OpenSSH 3.4p1. So yes, we are at risk.

      Check your system. In terminal type:
      sshd -v
  4. Re:deceit. by zulux · · Score: 4, Informative

    Given that the default install has ssh turned on, will they change it to "two remote holes" ?

    If you look carefully at the bug - at first glance, it lookls like when SSHD faluts out, some extra memory will be wiped with nulls.

    Perhaps there's more to this but basically whats is going on

    SSHD need more memory.
    Memrory counter is added to.
    Memeory is allocated.
    Repeat (until memory allocation fails)

    then...

    Because SSHD needs to wipe all it's memory to null so no crpto stuff is left lying around, all the memory pointed to my them memory counter is wiped. But unfortunalty some of that memory doesen't belong to SSHD because the memory allocation failed.

    --

    Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.

  5. So what? by pbrammer · · Score: 2, Informative

    All of the other vendors released similar bulletins... Most of them questioned the validity of this hole, but to be safe, they issued these notes to their customers to update OpenSSH. I know RedHat and Mandrake did.

    Phil

    1. Re:So what? by MavEtJu · · Score: 2, Insightful

      It wasn't so much an exploit but more a denial of service.

      If there is a way for third parties to disable a service running on my computer, yes I would like to be informed by it :-)

      --
      bash$ :(){ :|:&};:
  6. Re:deceit. by sirket · · Score: 2, Insightful

    This isn't a hole on OpenBSD. According to Theo this can only crash SSHD, not give access.

    -sirket

  7. Hey give us trolls a chance by Anonymous Coward · · Score: 3, Funny

    We only come out at night...

  8. Re:for FreeBSD 4.8 by MavEtJu · · Score: 4, Funny

    congratulations, you just have let your old sshd reread its configuration instead of stopping it and starting the new one.

    --
    bash$ :(){ :|:&};:
  9. Re:deceit. by R.Caley · · Score: 2, Interesting
    [...]But if someone can just crash it remotely without even getting to a shell it's not a hole? That doesn't makes sense to me.

    The difference is that if they could get even a very limited shell, that would turn all the local exploit bugs into potential remote exploit holes. That is clearly an order of magnitude more dangerous than a simple DOS.

    So, I think it makes sense to distinguish between the two cases, though I think just talking about `holes' is silly. Didn't they used to have `remote root exploit' or similar wording in there? Perhaps the PHBs didn't understand.

    --
    _O_
    .|<
    The named which can be named is not the true named