Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 24 reacties
Bron: OpenSSH announce

Nog voordat de er een aankondiging te vinden is op de site van wist siebrand ons al te nederlandse FTP-mirror staan de RPM's en sources al beschikbaar van deze 3.3-versie. Hieronder de lijst met wijzigingen:

Security Changes:
  • improved support for privilege separation:
  • Privilege separation is now enabled by default
  • ssh no longer needs to be installed setuid root for protocol
    version 2 hostbased authentication, see ssh-keysign(8).
    protocol version 1 rhosts-rsa authentication still requires privileges
    and is not recommended.
    Other Changes:
  • documentation for the client and server configuration options have been moved to ssh_config(5) and sshd_config(5).
  • the server now supports the Compression option, see sshd_config(5).
  • the client options RhostsRSAAuthentication and RhostsAuthentication now default to no, see ssh_config(5).
  • the client options FallBackToRsh and UseRsh are deprecated.
  • ssh-agent now supports locking and timeouts for keys, see ssh-add(1).
  • ssh-agent can now bind to unix-domain sockets given on the command line, see ssh-agent(1).
  • fixes problems with valid RSA signatures from putty clients.
  • Lees meer over

    Besturingssystemen:Windows 9x, Windows NT, Windows 2000, Linux, BSD, Windows XP, Linux x86, Mac OS Classic, macOS, OS/2, Solaris, UNIX
    Website:OpenSSH announce
    Moderatie-faq Wijzig weergave

    Reacties (24)

    D'r is een sploit voor uitgekomen. Wordt nu nog 'stilgehouden'.

    Dus upgraden is STERK aan te raden. Ik hoorde het vanmiddag al. De grote distributeurs krijgen nu de kans om hun packages up te daten. Vandaar dat die sploit nog wordt stil gehouden...

    /edit: alle versies tot 3.3 zouden lek zijn trouwens..
    Waarom moet MAZZA nou weer gelijk hebben. Dit komt net m'n meelbox binnen:
    On Mon, Jun 24, 2002 at 03:00:10PM -0600, Theo de Raadt wrote:
    > Date: Mon, 24 Jun 2002 15:00:10 -0600
    > From: Theo de Raadt <>
    > Subject: Upcoming OpenSSH vulnerability
    > To:
    > Cc:
    > Cc:
    > Cc:
    > There is an upcoming OpenSSH vulnerability that we're working on with
    > ISS. Details will be published early next week.
    > However, I can say that when OpenSSH's sshd(8) is running with priv
    > seperation, the bug cannot be exploited.
    > OpenSSH 3.3p was released a few days ago, with various improvements
    > but in particular, it significantly improves the Linux and Solaris
    > support for priv sep. However, it is not yet perfect. Compression is
    > disabled on some systems, and the many varieties of PAM are causing
    > major headaches.
    > However, everyone should update to OpenSSH 3.3 immediately, and enable
    > priv seperation in their ssh daemons, by setting this in your
    > /etc/ssh/sshd_config file:
    > UsePrivilegeSeparation yes
    > Depending on what your system is, privsep may break some ssh
    > functionality. However, with privsep turned on, you are immune from
    > at least one remote hole. Understand?
    > 3.3 does not contain a fix for this upcoming bug.
    > If priv seperation does not work on your operating system, you need to
    > work with your vendor so that we get patches to make it work on your
    > system. Our developers are swamped enough without trying to support
    > the myriad of PAM and other issues which exist in various systems.
    > You must call on your vendors to help us.
    > Basically, OpenSSH sshd(8) is something like 27000 lines of code. A
    > lot of that runs as root. But when UsePrivilegeSeparation is enabled,
    > the daemon splits into two parts. A part containing about 2500 lines
    > of code remains as root, and the rest of the code is shoved into a
    > chroot-jail without any privs. This makes the daemon less vulnerable
    > to attack.
    > We've been trying to warn vendors about 3.3 and the need for privsep,
    > but they really have not heeded our call for assistance. They have
    > basically ignored us. Some, like Alan Cox, even went further stating
    > that privsep was not being worked on because "Nobody provided any info
    > which proves the problem, and many people dont trust you theo" and
    > suggested I "might be feeding everyone a trojan" (I think I'll publish
    > that letter -- it is just so funny). HP's representative was
    > downright rude, but that is OK because Compaq is retiring him. Except
    > for Solar Designer, I think none of them has helped the OpenSSH
    > portable developers make privsep work better on their systems.
    > Apparently Solar Designer is the only person who understands the need
    > for this stuff.
    > So, if vendors would JUMP and get it working better, and send us
    > patches IMMEDIATELY, we can perhaps make a 3.3.1p release on Friday
    > which supports these systems better. So send patches by Thursday
    > night please. Then on Tuesday or Wednesday the complete bug report
    > with patches (and exploits soon after I am sure) will hit BUGTRAQ.
    > Let me repeat: even if the bug exists in a privsep'd sshd, it is not
    > exploitable. Clearly we cannot yet publish what the bug is, or
    > provide anyone with the real patch, but we can try to get maximum
    > deployement of privsep, and therefore make it hurt less when the
    > problem is published.
    > So please push your vendor to get us maximally working privsep patches
    > as soon as possible!
    > We've given most vendors since Friday last week until Thursday to get
    > privsep working well for you so that when the announcement comes out
    > next week their customers are immunized. That is nearly a full week
    > (but they have already wasted a weekend and a Monday). Really I think
    > this is the best we can hope to do (this thing will eventually leak,
    > at which point the details will be published).
    > Customers can judge their vendors by how they respond to this issue.
    > OpenBSD and NetBSD users should also update to OpenSSH 3.3 right away.
    > On OpenBSD privsep works flawlessly, and I have reports that is also
    > true on NetBSD. All other systems appear to have minor or major
    > weaknesses when this code is running.
    > (securityfocus postmaster; please post this through immediately, since
    > i have bcc'd over 30 other places..)
    _______________________________________________ mailing list
    Dus toch een lekje :(
    Ouch :P

    jij heb uhm dan zeker niet via bugtraq@securityfocus binnengekregen want ik heb uhm nog niet ontvangen. :(

    iig bedankt, compiling ;)
    jij heb uhm dan zeker niet via bugtraq@securityfocus binnengekregen want ik heb uhm nog niet ontvangen mailing list
    ^^^ Nej dus, via openssh-unix-announce :)
    Toch knap dat announce nu is eerder is dan bugtraq :)
    Dit meen je toch niet serieus he?

    Het probleem met SSH upgraden is nl. dat ik geen telnet heb en geen monitor op m'n servertje heb hangen. Het upgraden is dus niet echt supermakkelijk. :(
    Want als je vanuit een SSH sessie upgrade klapt je SSH sessie EN deamon eruit. Tenminste, dat zijn mijn ervaringen.
    Dat is niet mijn ervaring.
    Je kunt het proces van je huidige login laten draaien, en alleen het "hoofd"-proces killen. Daarna sshd opnieuw opstarten, en testen of je in kunt loggen.

    Ik gebruik gewoon:
    service sshd restart
    En dat werkt altijd tenminste.
    Whehehe, ik zal het proberen :) Hoofdproces dus killen en m'n eigen proces laten draaien.
    Overigens is het hele commando "telnet" en "telnetd" not found op mijn linuxservertje hoor :)
    Dus telnetten gaat niet 123 :P

    Hmm, ik kijk er morgen wel ff naar, ik gooi SSH nu wel ff dicht in de vuurmuur.
    kill `cat /var/run/`

    log nieuwe sessie in, en vervolgens alle oude sessies uit.
    Let erop dat je Priviledge seperation AAN zet, anders ben je als ik het goed begrijp nog steeds lek.
    Als je al een sshd_config file heb wordt ie mischien wel niet overschreven.

    BTW: die ` zijn backticks, op de knop van de tilde op US keyboards !!
    Het werkte :)
    Ik heb het hoofdproces gekilled en toen make install gedaan en ssh weer gestart en dat werkte.

    Priv sep heb ik geforceerd aangezet in de config file, dus dat zal wel goed zitten ;)
    Zet je telnet even open op een hoge poort...
    Of maak je een firewall rule dat telnet alleen vanaf jouw bak werkt.
    # Privilege separation is now enabled by default
    Was je error daarmee gerelateerd? :)

    je moet de README.privsep (oid) lezen in de source distributie...

    edit: reactie op Coen Rosdorff
    Nee niet daarmee.

    Het blijkt een probleem met kernel 2.2 en mmap te zijn.
    Thread op google

    Met het disablen van de compressie is het probleem opgelost. (Nou ja, het treed iig niet meer op)
    Ik heb deze zaterdagavond al geprobeerd te installeren op een server. Geen succes helaas. (Geeft een wazige error in de logs)

    Ik hou het nog maar even bij 3.2.3
    Als ik hem compileer op Slack8.1 krijg ik massa's "pointer of type 'void *' used in arithmetic". De uiteindelijke daemon wil ook niet meer mijn password accepteren. Iemand meer succes gehad?
    Check de FAQ @ over Slackware 7 oid :)
    Bij slackware moet het blijkbaar zo:
    ./configure LIBS=-lcrypt

    Dat van die pointer dingen had ik ook, het schijnt prima te werken.
    Voor de debbers onder ons:

    deb woody/updates main contrib non-free
    deb stable/updates main contrib non-free

    update sites van Debian woody en Debian potato, ff in /etc/apt/sources.list zetten, apt-get update, apt-get upgrade en je SSH hoort weer veilig te zijn :)
    Blijft dat de bug nog niet opgelost is, maar dat-ie door PrivSep te gebruiken niet exploitable zou zijn...
    hmms :

    > Basically, OpenSSH sshd(8) is something like 27000 lines of code. A
    > lot of that runs as root. But when UsePrivilegeSeparation is enabled,
    > the daemon splits into two parts. A part containing about 2500 lines
    > of code remains as root, and the rest of the code is shoved into a
    > chroot-jail without any privs. This makes the daemon less vulnerable
    > to attack.

    maar sshd draait gewoon als root
    moet je hem nou ook als andere user starten ? (en binary als chroot draaien ?)
    Log maar in als non root user remote en bekijk dan welke SSH processen er draaien. sshd splits een gedeelte af, dropt root privs en chroot het proces naar /var/empty
    Versie 3.3 is een tussenversie waarin de UsePriviledgeSeparation optie is aangezet, komende maandag komt versie 3.4 uit met de echte patch.
    Ik heb mijn manier van OpenSSH onder FreeBSD upgraden maar even gauw in een guide geklopt. Leek me wel zo handig, was zelf namelijk ook lang op zoek naar eenduidige instructies om OpenSSH onder FreeBSD te upgraden... Laat ajb even weten als 't ook voor jou werkt!
    Install werkte bij mij gewoon goed, ja, ik ben nog een RedHat bitch ;). Draai nu onder 3.3p1-1 =]. And of course met UsePrivilegeSeparation yes.

    Op dit item kan niet meer gereageerd worden.

    Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

    © 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en de Persgroep Online Services B.V. Hosting door True