...

Is there already an update for the new openssh (2.5.2p2) version which includes various security fixes?

I think in the discussion a few weeks ago it turned out that SuSE's default policy is to only offer patched versions of packages they ship with their CD's, i.e. if there is no security hole there probably won't be a feature upgrade.

If there is a security problem, we will fix it, especially if security-related software is concerned. The case of openssh is a mixed one: There is no imminent security threat with the versions we have out on the ftp server right now. Anyway, we have made updates, but we see some problems with them. Give us another few days and we'll have them fixed. The packages will be provided for the SuSE distributions that included openssh already. The others will not see updates because the package may not even compile on them.

But I'm just in the course of building rpms for SuSE 7.0 (maybe SuSE 7.1) and I will offer the rpms, the spec file as well as a short instruction on building openssh for SuSE from source rpm (which you can download from www.openssh.org) on our web site, so stay tuned. With an appropriate spec file, it's a one-liner. By the way, I was surprised at how many people actually downloaded the binary rpm for openssh-2.5.1p1 from our web site Though I don't have any bad intentions at all, you should have no reason to trust me, and _never_ download security sensitive packages from untrusted sources. Anyway, it was a nice field test on how far you _could_ probably get with "social engineering" in security mailing lists. Maybe Kurt wants to write an article on that subject ...? ;-)

Ack. It's sad. I believe Kurt has some sad articles about this already... :-)

...

Best wishes

Norbert

Regards, Martin

Thanks, Roman. -- - - | Roman Drahtmüller // "Caution: Cape does | SuSE GmbH - Security Phone: // not enable user to fly." | Nürnberg, Germany +49-911-740530 // (Batman Costume warning label) | - -

...

Ack. It's sad. I believe Kurt has some sad articles about this already... :-)

99% probability. BTW great work Kurt! ;-)

Huh? I missed a few messages (checks archives...) ok. Yeah, me too, running cryptoarchive bothers me, a) not to many people download the sig files for tarballs, and b) many many people installed my solaris ssh packages (which of course are glorified tarballs I built). It's amazing what people will install. I've actually got an upcoming article on the importance of getting keys from trusted places, the assumption being all developers at least include a signature in another file (i.e. detached sig) and more importantly that people check them (rmemeber ftp.win.tue.nl getting hacked? like 60 downloads before someone checked the pgp sig and alerted them). BTW the next email should amuse you all.

...

Thanks, Roman.

Regards, Martin --

Kurt Seifried, seifried@securityportal.com Securityportal - your focal point for security on the 'net

SecurityPortal Security Advisory SPSA-2001-0001 http://www.securityportal.com/articles/advisory20010001.html Title: RPM PGP/GnuPG verification bug Issue date: Feb 27, 2001 History of advisory: Feb 23, 2001 Ben De Rydt (ben dot de dot rydt at pandora dot be) brought this to my attention. Feb 27, 2001 advisory written and released to Linux vendor list, vendors notified. Feb 28, 2001 updated, thanks to Olaf Kirch for mentioning automatic key downloads. Author: Kurt Seifried seifried@securityportal.com Credits: Ben De Rydt (ben dot de dot rydt at pandora dot be) originally brought this to my attention, thanks go to him. Olaf Kirch (okir@caldera.de) for mentioning automatic key downloads and macros (which I read in the man page but mentally skipped over). Overview: There is a significant implementation/logic bug in how RPM verifies the cryptographic signatures on RPM files. Vendor Contact: N/A Impact: An attacker can create RPM's that will appear to be legitimate to the administrator, once installed root access (or anything else) can easily be achieved. Details: If an attacker can trick an administrator into installing an RPM checking the signature on the RPM can easily be subverted, thus the trojan'ed RPM is installed and the attacker can gain access. If an attacker can trick an administrator into installing a new key, or the administrator has enabled automatic key downloads, and provide them with a trojan'ed rpm file they can gain root access. No local access is required. Getting an admin to install a new key can be as simple as posting fake keys with identities like "secure@vendor.foo" or by simply emailing them to administrators with a subject line such as "new vendor key, please use to verify future rpm packages". Getting the administrator to download trojan'ed packages is attainable by poisoning DNS, spoofing a site, or breaking into a major RPM ftp site. 1) Attacker creates fake key, "secure@vendor.foo" 2) Attacker creates trojan'ed RPM, signs with fake key 3) Attacker sends key to victim, via email or otherwise, or victim has "automatic key download" enabled (note: it is common for vendors to send out self signed keys on various mailing lists) 4) Attacker either spoofs an update site, or breaks into a legitimate update site, replaces the real RPM with their trojan'ed RPM 5) User downloads RPM, verifies it (examples sanitized): [root@server /root]# rpm -K gnupg-1.0.1-1.i386.rpm /root/RPMS/gnupg-1.0.2-4.i386.rpm: md5 gpg OK Even with an "rpm -Kvv": [root@stench /root]# rpm -Kvv /root/RPMS/gnupg-1.0.1-1.i386.rpm D: New Header signature D: Signature size: 149 D: Signature pad : 3 D: sigsize : 152 D: Header + Archive: 709097 D: expected size : 709097 /root/RPMS/gnupg-1.0.2-4.i386.rpm: MD5 sum OK: 005707d7f35fc754dc5402462caf2ef6 gpg: Signature made Wed 30 Aug 2000 04:14:57 PM MDT using DSA key ID DB42A60E gpg: Good signature from "Vendor, Inc " gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. gpg: Fingerprint: CA20 8686 2BD6 9DFC 65F6 ECC4 2191 80CD DB42 A60E Please note that this is from a default install of a recent Linux distribution, error messages such as "WARNING: This key is not certified with a trusted signature!" are likely to be ignored (or they may have signed the attackers fake key). Unless the user checks the fingerprint of the key against a known good list (the key ID is not resistant to collision and can be faked) they will be none the wiser that this is an attackers key and RPM, and not a legitimate vendors. Due to the burden placed on the victim by this attack it is considered unlikely (unless of course automatic key downloads are enabled, in which case it is significantly easier) that widespread attacks based on it will happen. However an internal attacker, using this technique, does stand a good chance of leveraging access to other machines if the administrators are not sufficiently careful. This also underscores the need to provide users with more information when verifying cryptographically signed data, and the importance of securely storing keyrings. Solutions and workarounds: Disable automatic key downloads if they are enabled. Ideally you should create a seperate keyring with only the vendor keys on it to verify rpm's. Add the following lines to /etc/rpm/macros: %_signature gpg %_gpg_path /etc/rpm-keys/ In this example the files: options pubring.gpg secring.gpg trustdb.gpg will be placed into the directory /etc/rpm-keys/. Using rpm to verify packages will result in this keyring being used, and not root's default keyring. Do not install additional keys into root's keyring or the system one used to verify RPM's, and protect this keyring. Verify through a trusted channel any new vendor keys (e.g. many vendors now place them on distribution CD's). You can protect root's or the system keyring with the simple expedient of setting it read-only or immutable (on ext2): # chmod a-w /root/.gnupg/pubring.gpg or # chattr +i /root/.gnupg/pubring.gpg This will prevent accidental or casual insertion of new keys. If you have many keys in either keyring you should make sure to verify the fingerprint every time you check a package's signature. Vendors that ship RPM update tools should use a separate keyring (instead of root's) for verifying RPM's that are downloaded. References: [man page] rpm(8) [url] http://www.rpmdp.org/ -------------------------------------------------------------------------------- Permission is granted for copying and circulating this Bulletin to SecurityPortal (SP) customers (or the Internet community) for the purpose of alerting them to problems, if and only if, the Bulletin is not edited or changed in any way, is attributed to SP, and provided such reproduction and/or distribution is performed for non-commercial purposes. Any other use of this information is prohibited. SP is not liable for any misuse of this information by any third party.

The point is this: with automatic keydownload the attacker doesn't need to get a key to the victim. Without the attacker simply sends out a new self signed key and makes it appear as if from the vendor, in the last month several vendors have issued new keys, all self signed, posted to various mailing lists/etc. Do you 100% trust the security of all your mirror sites? Do you 100% trust your dns server, especially now with more people using autorpm/rhupdate/etc? Will SuSE be fixing this ala caldera/others? -Kurt