[SECURITY] [DSA 616-1] New telnetd-ssl packages fix arbitrary code execution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 616-1 [EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze December 23rd, 2004 http://www.debian.org/security/faq - -- Package: netkit-telnet-ssl Vulnerability : format string Problem-Type : remote Debian-specific: no CVE ID : CAN-2004-0998 Joel Eriksson discovered a format string vulnerability in telnetd-ssl which may be able to lead to the execution of arbitrary code on the victims machine. For the stable distribution (woody) this problem has been fixed in version 0.17.17+0.1-2woody3. For the unstable distribution (sid) this problem has been fixed in version 0.17.24+0.1-6. We recommend that you upgrade your immediately package. Upgrade Instructions - wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 3.0 alias woody - Source archives: http://security.debian.org/pool/updates/main/n/netkit-telnet-ssl/netkit-telnet-ssl_0.17.17+0.1-2woody3.dsc Size/MD5 checksum: 669 1911a91198987efcbfeaf54ba94994e2 http://security.debian.org/pool/updates/main/n/netkit-telnet-ssl/netkit-telnet-ssl_0.17.17+0.1-2woody3.diff.gz Size/MD5 checksum: 8721 901621f6abc0c1c6dc0713570994acf7 http://security.debian.org/pool/updates/main/n/netkit-telnet-ssl/netkit-telnet-ssl_0.17.17+0.1.orig.tar.gz Size/MD5 checksum: 167658 faf2d112bc4d44f522bad3bc73da8d6d Alpha architecture: http://security.debian.org/pool/updates/main/n/netkit-telnet-ssl/telnet-ssl_0.17.17+0.1-2woody3_alpha.deb Size/MD5 checksum: 101104 b3e71d1b626e6f618bba5e337c5e0221 http://security.debian.org/pool/updates/main/n/netkit-telnet-ssl/telnetd-ssl_0.17.17+0.1-2woody3_alpha.deb Size/MD5 checksum:56962 847abe42f9b4f910156239c85b35e2a7 ARM architecture: http://security.debian.org/pool/updates/main/n/netkit-telnet-ssl/telnet-ssl_0.17.17+0.1-2woody3_arm.deb Size/MD5 checksum:85194 1db7e7432d8025531b869ae5c737014b http://security.debian.org/pool/updates/main/n/netkit-telnet-ssl/telnetd-ssl_0.17.17+0.1-2woody3_arm.deb Size/MD5 checksum:48596 ad29db7a35ad3ee4e3d2c5c411b0edb9 Intel IA-32 architecture: http://security.debian.org/pool/updates/main/n/netkit-telnet-ssl/telnet-ssl_0.17.17+0.1-2woody3_i386.deb Size/MD5 checksum:85512 60cc558b94c132683259dcf6cce07874 http://security.debian.org/pool/updates/main/n/netkit-telnet-ssl/telnetd-ssl_0.17.17+0.1-2woody3_i386.deb Size/MD5 checksum:46708 1554de5105f77ebad4168c80d2cc4e83 Intel IA-64 architecture: http://security.debian.org/pool/updates/main/n/netkit-telnet-ssl/telnet-ssl_0.17.17+0.1-2woody3_ia64.deb Size/MD5 checksum: 123206 f04a1406feca437cd7acfd38214ea1d9 http://security.debian.org/pool/updates/main/n/netkit-telnet-ssl/telnetd-ssl_0.17.17+0.1-2woody3_ia64.deb Size/MD5 checksum:8 b87ace7ba0732798804ed9c247805d2d HP Precision architecture: http://security.debian.org/pool/updates/main/n/netkit-telnet-ssl/telnet-ssl_0.17.17+0.1-2woody3_hppa.deb Size/MD5 checksum:86580 d02c49d43f91bd4b1509fe71d15bbc6f http://security.debian.org/pool/updates/main/n/netkit-telnet-ssl/telnetd-ssl_0.17.17+0.1-2woody3_hppa.deb Size/MD5 checksum:53920 d8b9f61a1203571b667159f834623157 Motorola 680x0 architecture: http://security.debian.org/pool/updates/main/n/netkit-telnet-ssl/telnet-ssl_0.17.17+0.1-2woody3_m68k.deb Size/MD5 checksum:81420 437597b90358da1afee0818adf1c7242 http://security.debian.org/pool/updates/main/n/netkit-telnet-ssl/telnetd-ssl_0.17.17+0.1-2woody3_m68k.deb Size/MD5 checksum:45430 6bffe1c28aab33caa01bd26305029aac Big endian MIPS architecture: http://security.debian.org/pool/updates/main/n/netkit-telnet-ssl/telnet-ssl_0.17.17+0.1-2woody3_mips.deb Size/MD5 checksum:97400 1af9df6a844768e2bb26a613044737e3 http://security.debian.org/pool/updates/main/n/netkit-telnet-ssl/telnetd-ssl_0.17.17+0.1-2woody3_mips.deb Size/MD5 checksum:52270 c94b3bfb596075ab4b6444a9976f3988 Little endian MIPS architecture: http://security.debian.org/pool/updates/main/n/netkit-telnet-ssl/telnet-ssl_0.17.17+0.1-2woody3_mipsel.deb Size/MD5 checksum:97254 a9e36f6f8ae3056d0d81434740c42640
PHP Update .. details
It's looking like there won't be an update to PHP for Woody, because
the majority of the PHP issues aren't relevent.
Initially a few CVE numbers were assigned and then later withdrawn
when it became clear that the issues could only be exploited by a
user who wrote a malicious PHP script - not a remote issue, or too
serious. (Given that if you had the ability to write evil PHP code
you cold just run 'system('rm ..');'.
So .. there are two CVE IDs that are left:
CAN-2004-1019
- http://www.hardened-php.net/advisories/012004.txt
- Woody not vulnerable.
CAN-2004-1065
- http://msgs.securepoint.com/cgi-bin/get/bugtraq0412/157.html
- Woody not vulnerable.
All other CVE ID's were withdrawn, such as :
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1018
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1064
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1063
For all those people offering to help by investigating the problems
or looking at patches - thanks.
For all those people merely complaining that a new update wasn't
immediately available .. your patience is appreciated.
(And for anybody still confused about the worm going around,
that's something only affecting PHPBB - updated PHP wouldn't help that
at all anyway).
Steve
--
www.debian-administration.org
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PHP Update .. details
Hi!
It's looking like there won't be an update to PHP for Woody, because
the majority of the PHP issues aren't relevent.
Initially a few CVE numbers were assigned and then later withdrawn
when it became clear that the issues could only be exploited by a
user who wrote a malicious PHP script - not a remote issue, or too
serious. (Given that if you had the ability to write evil PHP code
you cold just run 'system('rm ..');'.
Unfortunately those vulnerabilities can be exploited by a user to
execute arbitrary code with the priviledges of the user running the
web server (www-data on woody). This defeats the purpose of the PHP
safe mode (http://www.php.net/manual/en/features.safe-mode.php) on
which many ISPs rely.
If the Debian project does not want to fix those issues IMHO Debian
should make an official statement that using the PHP safe mode with
Debian Woody does not offer the security one would expect.
Regards,
Hans
--
Hans Kratz
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: php vulnerabilities
also sprach Christophe Chisogne [EMAIL PROTECTED] [2004.12.22.1504 +0100]: In a few words: perhaps he's not Debian Developper (I dont know), but he's well know in the (french) PHP world, and net/sys-admin for nexentservices.com. So, competence probably is there. Trust a DD or trust that guy : it's a personnal choice You can trust him all you want. All I said was that you cannot trust him in the same way you trust a Debian developer. That was not supposed to be comparative. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: php vulnerabilities
Am 2004-12-22 15:55:38, schrieb Francesco P. Lovergine: BTW, I suspect RHE has a more relaxed policy for security, i.e. major upgrades are allowed when patching obsolete programs is impractical. This is right, but how many Packages do they have ? 1000 ? 2000 ? I think, it is no problem, to do this with a mini Distribution like RHE, but for Debian, which have curently 14.000 Source-Packages and over 15.600 Binary-Packages it is nearly impossibel. Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Martin Mifsud/ErnstYoung/MT is out of the office. [Email checked - EMEA]
I will be out of the office starting 22/12/2004 and will not return until 03/01/2005. I will respond to your message when I return. -- The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. Ernst Young is neither liable for the proper and complete transmission of the information contained in this communication nor for any delay in its receipt. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: php vulnerabilities
* Michael Stone: On Wed, Dec 22, 2004 at 03:03:29PM +0100, Florian Weimer wrote: My best guess is that things are fine until Debian is the last guy left in town, and no one else (upstream, other vendors) support the version in stable. Is this correct? Eh, and the other point I forgot to include is that other distributions aren't shy about just releasing a new version rather than backporting if the fix is non-trivial. I think such a policy makes sense. Actually, I don't think we have much choice. 8-/ However, most of our packages haven't got test suites, and our dependency graph is certainly more convoluted than Red Hat's. For example, Red Hat probably has only a handful packages which depend on PHP. How do we make sure that the upgrade does not break any of the PHP-based packages we ship? My current idea is to borrow an idea from Microsoft: Create a Patch Validation Program. Under this program, you get access to security fixes before the official release, and you can test if your applications break. Of course, Microsoft requires NDAs because they actually give you binaries a week or so before the regular patch day. Debian wouldn't be able to do this, so patch validation could begin only after the issue has been disclosed. We could use a separate public archive, and after some soaking period, the new packages could be officially released on security.debian.org. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: php vulnerabilities
On Thu, Dec 23, 2004 at 05:16:39PM +0100, Florian Weimer wrote: My current idea is to borrow an idea from Microsoft: Create a Patch Validation Program. Under this program, you get access to security fixes before the official release, and you can test if your applications break. Of course, Microsoft requires NDAs because they actually give you binaries a week or so before the regular patch day. Debian wouldn't be able to do this, so patch validation could begin only after the issue has been disclosed. We could use a separate public archive, and after some soaking period, the new packages could be officially released on security.debian.org. I think You are reinventing apt-listbugs ;-) -- )^o-o^|jabber: [EMAIL PROTECTED] | .v Ke-mail: jjminar FastMail FM ` - .' phone: +44(0)7981 738 696 \ __/Jan icq: 345 355 493 __|o|__Min irc: [EMAIL PROTECTED] pgpSAwQMEaNBJ.pgp Description: PGP signature
Re: php vulnerabilities
* Jan Minar: On Thu, Dec 23, 2004 at 05:16:39PM +0100, Florian Weimer wrote: My current idea is to borrow an idea from Microsoft: Create a Patch Validation Program. Under this program, you get access to security fixes before the official release, and you can test if your applications break. Of course, Microsoft requires NDAs because they actually give you binaries a week or so before the regular patch day. Debian wouldn't be able to do this, so patch validation could begin only after the issue has been disclosed. We could use a separate public archive, and after some soaking period, the new packages could be officially released on security.debian.org. I think You are reinventing apt-listbugs ;-) apt-listbugs only helps if someone else has already burned his fingers, *and* has filed a bug report with the proper severity and tags. IOW, the soaking period is required. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: php vulnerabilities
On Do, 23.12.2004, 21:16, Florian Weimer wrote: * Jan Minar: On Thu, Dec 23, 2004 at 05:16:39PM +0100, Florian Weimer wrote: My current idea is to borrow an idea from Microsoft: Create a Patch Validation Program. Under this program, you get access to security fixes before the official release, and you can test if your applications break. Of course, Microsoft requires NDAs because they actually give you binaries a week or so before the regular patch day. Debian wouldn't be able to do this, so patch validation could begin only after the issue has been disclosed. We could use a separate public archive, and after some soaking period, the new packages could be officially released on security.debian.org. I think You are reinventing apt-listbugs ;-) apt-listbugs only helps if someone else has already burned his fingers, *and* has filed a bug report with the proper severity and tags. IOW, the soaking period is required. And what is Debian 'unstable' now? ;) Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: php vulnerabilities
* Christian Storch: apt-listbugs only helps if someone else has already burned his fingers, *and* has filed a bug report with the proper severity and tags. IOW, the soaking period is required. And what is Debian 'unstable' now? Please try to understand the context of this discussion. We are talking (well, at least Michael and I are talking) about the situation were upstream (and thus unstable/testing) differ considerably from the version released with stable, that is, the case when security fixes cannot be backported with reasonable effort. Under these circumstances, it's naive to expect you can take the version from unstable, tweak it to build on stable, and release it without any integration tests. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: php vulnerabilities
In article [EMAIL PROTECTED] you wrote: IOW, the soaking period is required. But we don't hide Bugs. And given the voluntary nature of Debian a lot of fixes just wont happen before the velnerability is widely known, anyway. Just see the current samba problem. And besides the openssh disaster I dont see many destructive security patches, especially not with debians conservative backporting strategy. Greetings Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: php vulnerabilities
On Thu, Dec 23, 2004 at 10:26:34PM +0100, Christian Storch wrote: On Do, 23.12.2004, 21:16, Florian Weimer wrote: * Jan Minar: On Thu, Dec 23, 2004 at 05:16:39PM +0100, Florian Weimer wrote: My current idea is to borrow an idea from Microsoft: Create a Patch Validation Program. Under this program, you get access to security fixes before the official release, and you can test if your applications break. Of course, Microsoft requires NDAs because they actually give you binaries a week or so before the regular patch day. Debian wouldn't be able to do this, so patch validation could begin only after the issue has been disclosed. We could use a separate public archive, and after some soaking period, the new packages could be officially released on security.debian.org. I think You are reinventing apt-listbugs ;-) apt-listbugs only helps if someone else has already burned his fingers, *and* has filed a bug report with the proper severity and tags. You can tell it to install only packages that have been in the archive no less than some arbitrary period of time (or maybe not and it could be written; I don't use apt-bug). IOW, the soaking period is required. And what is Debian 'unstable' now? Security updates don't go thru unstable. There are lots of revised updates. Cheers, -- )^o-o^|jabber: [EMAIL PROTECTED] | .v Ke-mail: jjminar FastMail FM ` - .' phone: +44(0)7981 738 696 \ __/Jan icq: 345 355 493 __|o|__Min irc: [EMAIL PROTECTED] pgpKLZPg52h5t.pgp Description: PGP signature
Re: php vulnerabilities
* Bernd Eckenfels: In article [EMAIL PROTECTED] you wrote: IOW, the soaking period is required. But we don't hide Bugs. And given the voluntary nature of Debian a lot of fixes just wont happen before the velnerability is widely known, anyway. Just see the current samba problem. Sorry for being unclear. The soaking period starts *after* the issue has been published. And besides the openssh disaster I dont see many destructive security patches, especially not with debians conservative backporting strategy. That's because the potentially destructive patches simply don't happen. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: php vulnerabilities
On Thu, Dec 23, 2004 at 11:48:34PM +0100, Florian Weimer wrote: IOW, the soaking period is required. .. Sorry for being unclear. The soaking period starts *after* the issue has been published. This means we will not provide patches or does it mean we will provide them for the user to chose? The first is I guess not acceptable, and the later is current policy. You do not have to install the patches if you want to let the soak. Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://www.eckes.org/ o--o 1024D/E383CD7E [EMAIL PROTECTED] v:+497211603874 f:+497211606754 (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: php vulnerabilities
* Bernd Eckenfels: On Thu, Dec 23, 2004 at 11:48:34PM +0100, Florian Weimer wrote: IOW, the soaking period is required. .. Sorry for being unclear. The soaking period starts *after* the issue has been published. This means we will not provide patches or does it mean we will provide them for the user to chose? Users who want to provide a service to the community can pre-test patches and see if they break anything. Users who value security over functionality can do this, too. The first is I guess not acceptable, This is not a question of acceptance. It's only a last resort for packages for which security support cannot be provided in any other way. Look at the Mozilla version in stable, and the issues surrounding it, and you will understand. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: php vulnerabilities
* Jan Minar: apt-listbugs only helps if someone else has already burned his fingers, *and* has filed a bug report with the proper severity and tags. You can tell it to install only packages that have been in the archive no less than some arbitrary period of time (or maybe not and it could be written; I don't use apt-bug). One of the recent bugs which led to unstable breakage was already filed, but not with sufficient severity to trigger apt-listbugs. 8-( apt-listbugs is just kludge, not a real concept you can advertise to end users, IMHO. (Of course, the security process as a whole is nothing but a kludge, but there is little Debian can do about it.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: php vulnerabilities
Hallo Florian, On Fri, Dec 24, 2004 at 12:37:24AM +0100, Florian Weimer wrote: Look at the Mozilla version in stable, and the issues surrounding it, and you will understand. Yes, actually I really think that backporting is not possible nor effective in a lot of situations. And yes you are right, a new Upstream Version needs Soaking. However this discussion is therefore quite theoretical, I see currently nearly no way for any major update to slip into stable. Too much core maintainers would object. It is more likely the software is removed on an revision. (and i am not sure it that is a good solution, especially for commonly used programs) Mozilla is a quite interesting subject to study: It might break a lot of stuff if upgraded (due to the libs), and it is extremly complicated to backport the fixes (since no patch list is available). And even If (or especially when!) debian developers succeed in fixing all the bugs by backporting, the user would be frustrated by having to live with outdated versions. (I think this is true for most productvity applications and less true for server apps where a conservative patching means sense and is more common upstream anyway. (and less complicated to backport single fixes)). This is somewhat the microsoft problem - gui software and multi function packagaes are simply not sanely maintainable. Gruss Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://www.eckes.org/ o--o 1024D/E383CD7E [EMAIL PROTECTED] v:+497211603874 f:+497211606754 (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
