Re: Details on CVE-2016-10229: Remote code execution vulnerability in kernel networking subsystem
Hello, Am 04/04/2017 um 08:11 AM schrieb Salvatore Bonaccorso: > Hi > > On Tue, Apr 04, 2017 at 12:52:41AM +0200, Jan Lühr wrote: >> Hei folks, >> >> android recently patched CVE-2016-10229: Remote code execution >> vulnerability in kernel networking subsystem. >> >> Since https://security-tracker.debian.org/tracker/CVE-2016-10229 is >> rather blank ... does this problem exists in debian, too? > > The problem has been fixed in Debian stable already with > 3.16.7-ckt20-1+deb8u2. I have updated the tracker. Unfortunately that > is one of the CVE assigned by Android and assigned only later on. I > guess most distributions have the fixes already in their releases > (without CVE references). Thanks! Greetz, Jan -- There's a ripped off cord To my TV screen With a note saying: "Im not afraid to dream" -- Donkey Boy, Crazy Something Normal
Details on CVE-2016-10229: Remote code execution vulnerability in kernel networking subsystem
Hei folks, android recently patched CVE-2016-10229: Remote code execution vulnerability in kernel networking subsystem. Since https://security-tracker.debian.org/tracker/CVE-2016-10229 is rather blank ... does this problem exists in debian, too? Thanks, Jan -- There's a ripped off cord To my TV screen With a note saying: "Im not afraid to dream" -- Donkey Boy, Crazy Something Normal signature.asc Description: OpenPGP digital signature
Re: CVE-2016-7117 Remote code execution vulnerability in kernel networking subsystem
Hello, Am 10/04/2016 um 07:57 PM schrieb Nicholas Luedtke: > On 10/04/2016 11:40 AM, Felix Knecht wrote: > >> On 10/04/2016 06:38 PM, Jan Lühr wrote: >>> CVE-2016-7117 was patched in Android today.I don't see much information >>> right now. The title is rather frightening - the issue appears to be urgent. >> The following upstream kernel commit is referenced in the security bulletin: >> >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=34b88a68f26a75e4fded796f1a49c40f82234b7d >> >> No idea if this is fixed in Debian though. >> >> Felix >> > Looks like it was picked up when Debian rolled to 3.16.36-1. Thanks for the info - if Felix is right, then 4.7 (jessie backports) is secure, since it was released months after the fix was pushed to the mainline kernel. However, it's somewhat strange that a bug labeled "Linux Kernel Use-After-Free Remote Code Execution Vulnerability", concerning a lot of kernels released in the last years (http://www.securityfocus.com/bid/93304) seem to be fixed in android only. Do you know any details? Anyway, using jessie-backports seem to help, thus I'm going for it... Thanks, Greetz, Jan -- There's a ripped off cord To my TV screen With a note saying: "Im not afraid to dream" -- Donkey Boy, Crazy Something Normal signature.asc Description: OpenPGP digital signature
CVE-2016-7117 Remote code execution vulnerability in kernel networking subsystem
Hello, CVE-2016-7117 was patched in Android today.I don't see much information right now. The title is rather frightening - the issue appears to be urgent. Can you confirm, that common Debian installation are unaffected and cannot be taken over via CVE-2016-7117? If not, I'd like to shut down a few boxes, unless there's a patch or work-around. Greetz, yanosz -- There's a ripped off cord To my TV screen With a note saying: "Im not afraid to dream" -- Donkey Boy, Crazy Something Normal signature.asc Description: OpenPGP digital signature
Re: [SECURITY] [DSA 3481-1] glibc security update
Hello folks, thanks for providing a patch in Debian. One question: Am 02/16/2016 um 03:18 PM schrieb Salvatore Bonaccorso: > CVE-2015-7547 > > The Google Security Team and Red Hat discovered that the glibc Comparing the age (2015-07) and the severity: Can you give some details on the situation? Why was the bug fixed so late? Which parties influenced the release date? Are you aware of exploiting by APT-Groups or nation state actors? Thanks, Jan -- There's a ripped off cord To my TV screen With a note saying: "Im not afraid to dream" -- Donkey Boy, Crazy Something Normal signature.asc Description: OpenPGP digital signature
cmrekey.adv ?
Hello folks, short one: Is Debian GNU/Linux affected by http://www.openssh.com/txt/gcmrekey.adv ? Thanks, Keep smiling yanosz signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [volatile] Updated clamav-related packages available fortesting
Hello, On Friday 16 April 2010 10:01:46 you wrote: Hi, Jason Self wrote/schrieb @ 15.04.2010 21:52: Kurt Roeckx k...@roeckx.be wrote .. What does this mean exactly? deb http://volatile.debian.org/debian-volatile \ lenny-proposed-updates/volatile main contrib non-free The imho more interesting point is: What does it mean in the long term? The current situation is: Volatile has clamav 0.95, while upstream has 0.96. There are security related issues in 0.95 (DoS etc.?) [1] that might affect(?) volatile - futhermore the clamav-people are suggesting to use the latest version [2] - that is 0.96. Volatile itself is not supported by the security team [3] and the security team refuses the support the current stable version [4]. As a sysop running lenny/clamav on a few hosts, I started building clamav from source and reading clamav's announce list. But I wonder, what does it mean in the long run: - Will volatile be updated to 0.96 soon? - Will clamav (in volatile) receive official security support? - Are there any (better supported) alternatives to clamav in lenny? - Afair there is no specific EOL-/Kill-Switch in clamav: ClamAV = 0.94 is unable to handle big incremental updates and a too big update was shipped. Is it - from a naive point of view - just a bug that can be fixed in debian [5]? Just apply the given patch [6] in lenny's clamav and be happy? ;-) Thanks, Keep smiling yanosz [1] http://git.clamav.net/gitweb?p=clamav-devel.git;a=blob_plain;f=ChangeLog;hb=clamav-0.95.3 [2] http://www.clamav.net/lang/en/2009/10/05/eol-clamav-094/ [3] http://www.debian.org/volatile/index.en.html [4] http://lists.debian.org/debian-security-announce/2009/msg00228.html [5] https://wwws.clamav.net/bugzilla/show_bug.cgi?id=1395 [6] https://wwws.clamav.net/bugzilla/show_bug.cgi?id=1395#c12 -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201004182252.41966.debian-secur...@stephan.homeunix.net
Re: [volatile] Updated clamav-related packages available fortesting
Hello, On Sunday 18 April 2010 22:52:41 Jan Lühr wrote: Hello, On Friday 16 April 2010 10:01:46 you wrote: Hi, Jason Self wrote/schrieb @ 15.04.2010 21:52: Kurt Roeckx k...@roeckx.be wrote .. What does this mean exactly? deb http://volatile.debian.org/debian-volatile \ lenny-proposed-updates/volatile main contrib non-free The imho more interesting point is: What does it mean in the long term? The current situation is: Volatile has clamav 0.95, while upstream has 0.96. There are security related issues in 0.95 (DoS etc.?) [1] that might affect(?) volatile - [1] http://git.clamav.net/gitweb?p=clamav-devel.git;a=blob_plain;f=ChangeLog;hb =clamav-0.95.3 [2] http://www.clamav.net/lang/en/2009/10/05/eol-clamav-094/ sorry, [1] was meant to be http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=577462 Keep smiling yanosz -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201004182305.36598.debian-secur...@stephan.homeunix.net
Re: Timeliness of Debian Security Announceness? (DSA 756-1 Squirrelmail)
Greetings, Am Donnerstag, 14. Juli 2005 17:40 schrieb Herwig Wittmann: Hi! I am trying to understand if my organization can rely on the debian security announcement mailing list as only source of security alerts in the future. This would be very convenient- but the delay that seems to have passed between the original squirrelmail security announcement and the time I received the alert via [EMAIL PROTECTED] is worrying: If you've been following debian for at least a couple of months, you got to know, that this issue was fixed rather fast. However, my - one and only - advice in this case is: Don't use debian packages, if this is vital for you! Keep smiling yanosz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Security Support in Place
(open letter to the debian security team) Greetings,.. on friday, 8th july 2005 07:58 Martin Schulze wrote: [...] The Debian project confirms that the security infrastructure for both the current release Debian GNU/Linux 3.1 (alias sarge) and the former release 3.0 (alias woody) is working again. The security team is now able to provide updates on a regular basis again. [...] There were several issues with the security infrastructure after the release of sarge, that lead to the Debian security team being unable to issue updates to vulnerable packages. These issues have been fully resolved, and the infrastructure is working correctly again. Nice to hear, thanks to all. You obviously spent a lot of time and efforts in restoring debian security. Thanks. But maybe, some rather constructive critism is required as well- and ehm, well, to be honest, imho this is not satisfying: It has never been official announced, that the security infrastructure is not working. It is quite confusing, that you report the end of problems you haven't reported at first, furthermore if the end of this problem justifies an official debian announce, the beginning of this problem should have been announced to. Knowing a security problem is imho probably more important than knowing not having a problem, because, a security problem requires defensive actions. Another point is the explanation. several issues with the security infrastructure can probably mean anything. From failing power supplying units up to conflicts within the security team. By that the explanation is not satisfying, too. There has been a few rumours in joey's blog, but anyway, I'm missing official statements / announces, why this had happend (technically and non-technically) how it was solved, and how it is prevent in the future - and I guess, others are missing 'em as well. Looking back to the break-in 2003, this issue was handled very good and transparent. Imho this was a good example how things can be handled - thus going on that way ought to be quite better. Thanks for your patience, Keep smiling yanosz
Re: Question about Debian security policy
Greetings, Am Donnerstag, 30. Juni 2005 12:57 schrieb Paul Haesler: Hi everybody. I hope this question won't be too stupid. When I perform a standard installation (i.e minimal), the installer installs many servers, and launches them (like portmap, ssh, exim, etc). Why? I think that OpenBSD and FreeBSD, for example, don't launch any daemon at all, or at least prompt you before doing that. There must be a reason, but I don't see it (I'm not a networking/security guru, so please forgive me if the answer is obvious). I think you'll find OpenBSD launches at least sshd and sendmail in the default install (although sendmail only listens on loopback interface by default). I've always wondered about portmap in debian myself - I presume it's to do with NFS. Perhaps it has to be part of the base system to support network installs. When I last installed OpenBSD I was asked on whether I want so use ssh. It doesn't start automatically. Keep smiling yanosz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bad press related to (missing) Debian security
Greetings, Am Montag, 27. Juni 2005 15:54 schrieb Carl-Eric Menzel: On Mon, 27 Jun 2005 15:50:19 +0200, Jan Wagner [EMAIL PROTECTED] said: On Monday 27 June 2005 15:25, W. Borgert wrote: Just FYI: The well-known German Heise Newsticker (IT related) has an article today with the title Debian without security update for several weeks: http://www.heise.de/newsticker/meldung/61076 Hm, bad reputation for us... This was only a question of time .. :( Does anybody know what the actual problem is, i.e. why there are no updates? This is not an actual problem, this problem is rather imho structual. In it's last one to two years Woody was starving out of security updates. (Samba, Mozilla, Kernel, etc.). Keep smiling yanosz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bad press related to (missing) Debian security
Greetings, Am Montag, 27. Juni 2005 20:10 schrieb Adam Majer: Jan Lühr wrote: Greetings, Am Montag, 27. Juni 2005 15:54 schrieb Carl-Eric Menzel: Does anybody know what the actual problem is, i.e. why there are no updates? This is not an actual problem, this problem is rather imho structual. In it's last one to two years Woody was starving out of security updates. (Samba, Mozilla, Kernel, etc.). These are much less of a problem since they deal with either Intranet only applications (Samba), client side applications (mozilla) or the kernel that one usually rolls their own for their servers. What I really care about from Debian security team is up-to-date fixes for server applications that can be exposed to the Internet. For example, apache, squid, spamassassin, postfix, sendmail, exim, etc... I'm not refering to exploits / bugs in general. I'm refering to the patch-port-situation in Debian. Keep smiling yanosz
Re: SpamAssassin DOS-Fix anytime soon ?
Greetings,.. Am Donnerstag, 23. Juni 2005 13:42 schrieb [EMAIL PROTECTED]: Hi list, a remote-dos-vulnerability in spamassassin 3.0.1-3.0.3 was announced a week ago. while most other distributions have since then reacted on this a debian stable security fix seems still unavailable. on the package maintainer's page it says the fix is long done and is just waiting for the security-team to act on it [0]. so my question is: why has the fix not been released yet (after 7 days)? after all, a remotely exploitable bug in most mailreceiving systems should have a rather high priority. There is no reason to create a third threat for that issue. If you wanna have a secure Linux port dist the package by yourself or use SuSE. They fixed it already. fup2 previous threads. Keep smiling yanosz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Security Support by the Security-Team
Greetings, Am Samstag, 18. Juni 2005 09:04 schrieb Helmut Toplitzer: Hi! Just a few remarks: Use unstable or testing, and apply security fixes yourself. Over To my opinion this is a bad suggestion. Maybe my last mail was a bit unclear about this. As security is a process rather than a state, your systems will hardly ever have all the available security-patches. (Not to note that it's not possible to keep up with this job if you are alone with it, which will be the fact if you do it by hand for testing/unstable.) Well, not necessary, security, as done - is a process and and a state. You do either configure your deamons to run less-privilged chroot'ed or you don't. This is no process in this. So the question is how to deal with this. As every distribution has a security-team these days Not every... (or at least should have) it is possible to get the security-patches in (quite short) time. Well. what is a short time here? They established a processes how these patches get into the distributions and do a lot of communication with each other that none is missed. At least we hope. (And if you ever tried to, you will know that this is a quite complex job to do if you want to do it well.) Of course, at least consider the amount of packages. As result a lot of people rely on the work of these teams. Especially Debian has a very open way to do this. This is wrong, (more or less). Debian has access to non-disclosed information. If you interpret the d-s-c in a strict way, it is not allowed, too - but AFAIK this has never been a big issue (?) (However this is quite difficult to discuss, 'cause full- vs. non disclosure is not settled at all) Security problems a handled publicly if there's no request to do it not this way. No. So if you protect your systems (more than 2) by these updates, you would be well advised to establish a process yourself how you get them onto your system and how - in general - you keep them more or less secure. No. The truth is (at the moment and in the near past), that you have to backport the patches by yourself - But Debian offers a framework for porting. And the information if Debian-Security is working as expected is a very valuable one to people who did this. How do you define expected ? Debian security is not a just-in-time-patch delivery service working 24/7. Imho Debian security is a instance allowing patches to get into stable. So if you set up stable years after it's release, it is realistic to assume, that no vuln older than a couple of months/ weeks is included (if a patch is available). (Well, they were some, even in essential packages, but you'll know them if you follow this list) Hopefully my considerations are clear now. (This mail became much longer than I wanted.) Your consideration are quite clear, but imho you expect to much. I decided to stop moaning and criticizing because - I cannot do better - I don't pay them - they are volunteers - I don't have to use their services - I said a lot, I triggered some processes I don't like to have happened - I bashed on the wrong guys. Keep smiling yanosz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Security Support by the Security-Team
Greetings, Am Freitag, 17. Juni 2005 10:58 schrieb Florian Weimer: Rumors suggest that the technical foundations of security support for sarge and woody are working again. Nice to hear - however, a SpamAssassin-patch has to be ported to sarge.[1] Let's see... the Sec-Announce was posted ~2 days ago. I expect exploits to appear soon, considering the uhm, eh... commercial interest in delivering spam. Everyone is to invited, to count the number of days... Keep smiling yanosz [1] http://marc.theaimsgroup.com/?l=spamassassin-announcem=111886630726077w=2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Well - and kernel 2.4.18?
Greetings, Am Montag 04 April 2005 11:03 schrieb Moritz Muehlenhoff: Jan Lühr wrote: Is Samba going to be the next mozilla? The Sama 2.2 tree is obsolete and not provided with upstream fixes.[1] Have a look at the size of upstream's patch and you'll see why it took so long. Is there some? Refering to samba.org [1] this issues has not been fixed in the latest samba 2.2 release, released on Sept 29, 2004. Keep smiling yanosz [1] http://us4.samba.org/samba/history/samba-2.2.12.html
Well - and kernel 2.4.18?
Greetings, is there any progress in providing fixed kernels for stable? I was just wondering 'cause I expected 'em three months ago. Keep smiling yanosz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Well - and kernel 2.4.18?
Greetings, Am Sonntag 03 April 2005 22:57 schrieb Harald Krammer: Hi Jan, I had the same question but this is a while ago. At the moment I use kernel 2.4.27 from backport.org. Here is the link from the old thread: http://lists.debian.org/debian-security/2005/01/threads.html#00201 Me, too ;) However, I gave you some *explanation that time ;-) However, Btw. I'm quite worried about the Shape of Debian's security. Take CAN-2004-1154 [SECURITY] [DSA 701-1] New samba packages fix arbitrary code execution for instance. Fixed in Samba: 15th December 2004 (with 3.0.10 from samba.org) Fixed in SuSE: 22th December 2004 Fixed in Woody: 31st. March 2005 That ain't good. Keep smiling yanosz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Well - and kernel 2.4.18?
Greetings, Am Sonntag 03 April 2005 23:16 schrieb Jan Lhr: Greetings, Am Sonntag 03 April 2005 22:57 schrieb Harald Krammer: Hi Jan, I had the same question but this is a while ago. At the moment I use kernel 2.4.27 from backport.org. Here is the link from the old thread: http://lists.debian.org/debian-security/2005/01/threads.html#00201 Me, too ;) However, I gave you some *explanation that time ;-) However, Btw. I'm quite worried about the Shape of Debian's security. Take CAN-2004-1154 [SECURITY] [DSA 701-1] New samba packages fix arbitrary code execution for instance. Fixed in Samba: 15th December 2004 (with 3.0.10 from samba.org) Fixed in SuSE: 22th December 2004 Fixed in Woody: 31st. March 2005 That ain't good. Furthermore - it might be in important issue: Is Samba going to be the next mozilla? The Sama 2.2 tree is obsolete and not provided with upstream fixes.[1] The recently fixed issue, may be harmful. (Although I haven't seen any public exploits yet). On securityfocus it is characterized as possible _remote_ _root_ exploit. An attacker with access to an SMB share may leverage this issue to overwrite the heap of the affected process, facilitating code execution with superuser privileges. [1] Imho, this ain't very serios - but noticeable serious, 'cause 2004-1154 is the one and only listed common bug for 3.0.10 and apart of two minor changes 3.0.10 is a bugfix-release for 1154 [3]). Furthermore, Sarge is not freezed yet, thus praising the lord for not coming up any samba exploits 'till Sarge releases is foolish in my opinion. So what will Debian do? Samba is an integral part of many Debian servers out there... Keep smiling yanosz [1] http://us1.samba.org/samba/history/samba-2.2.12.html [2] http://www.securityfocus.com/bid/11973/discussion/ [3] http://us1.samba.org/samba/history/samba-3.0.13.html
Re: Kernel security advice
Greetings, Am Freitag, 18. Februar 2005 04:51 schrieb JM: Hello, * Besides grsecurity patch, pax etc...What other recommendations are there to patch a kernel on a woody or sarge production server? * Any experiences/opinions with the debian-hardened kernels? * Is it that terrible running X if access is not allowed from the network, only locally? I recently had some trouble with pax (gresecurity) and java (sun). Thus if you use tomcat etc., pax won't be an option. Keep smiling yanosz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Grsecurity patches on Debian
Greetings,.. Am Montag, 7. Februar 2005 14:10 schrieb Andras Got: Hi, You should start with grsec low and proc restricions set customly. Hardening your kernel is always a option. The grsec default high settings, and PaX break Jetty (java server container) in two, so it simply won't start, gradm won't help as I know. After the grsec default low settings you should read about the functions grsec has, and consider which one is good for you or worth using. I have grsec deafult high (+ the new extras set) kernels on gateways and one prod webserver. It works very well so far. Grsec+PaX itself won't break any program, that don't do anything wierd or unusual and suspicous. When you use chroot (postfix uses it by default), grsec can harden very vell your chroot systems. Well, once I had some trouble using wine on an openwall patched terminal server. I don't know, whetere these issue still apply. Keep smiling yanosz -- Achtung: Die E-Mail-Adresse [EMAIL PROTECTED] wird in Krze deaktiviert werden. Bitte nutzen Sie die Adresse [EMAIL PROTECTED]
Re: [OT] tales (was: woody kernel image)
Greetings, Am Sonntag, 30. Januar 2005 21:14 schrieb Alexander Schmehl: Hi! * Michelle Konzack [EMAIL PROTECTED] [050130 20:29]: how does it come, that every time, you're telling such a story and are requested for some proof, one of your services is down, you cite completly unrelated URLs or you don't answer at all? Why not go to http://lists.debian.org/ and search for it ? May I add this as an other case of MK makes statements which she can't proofe to my list? Making a statement, and telling others to proof it for themself doesn't make your argument look very good. But anyway, I'm subscribed to both lists, and all I can say is: Been there, done that, got no shirt. So until I'm showed otherwise, I'm convident, that there is no mail to debian-devel or debian-kernel, stating that support for the 2.4.18* kernels in the current stable release has been dropped. And beside that, Joeys, forwarded to this list by Jan Minar a couple of hours ago (id: [EMAIL PROTECTED]) proofes, that you are wrong. Don't take it down personal. Jugding about DSA's I've seen, there is currently _no_ security-support for 2.4.18. For reasons I don't know, for thinks, I don't understand, important patches seem to be missing. If you have information about the status of sec-sup in 2.4.18 please let us know. Keep smiling yanosz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [OT] tales (was: woody kernel image)
Greetings, Am Sonntag, 30. Januar 2005 22:46 schrieb Alexander Schmehl: * Jan Lühr [EMAIL PROTECTED] [050130 22:13]: Don't take it down personal. Jugding about DSA's I've seen, there is currently _no_ security-support for 2.4.18. I didn't made any statement about security support of 2.4.18. All I said was, that MK can't proof her own statement, that I can't a find a proof of it, and that we have a hint, contradicting her statement. yeah, yeah, yeah, please stop this flamewar. For reasons I don't know, for thinks, I don't understand, important patches seem to be missing. If you have information about the status of sec-sup in 2.4.18 please let us know. Did you read the mail from Joey Schulze forwarded by Jan Minar a couple of hours ago to this list? Security support for 2.4.18 kernels has not been dropped. It isn't nice, that the kernel-packages has not been upgraded, yet. But I'm sure, that the Security Team will gladly accept your help, if you send them working and tested patches. ACK, support hasn't been dropped officialy and Joey is doing a good job patching 2.4.27 - and I'm the last one complaining about not riding dead horses like old stable packages, as soon as packages can be backported from sid easily. (In other situtations - no I won't mention the m* word it is different). However, Imho users should be warned, that using woody is a security risk. Keep smiling yanosz
Re: woody kernel image
Greetings, Am Freitag, 28. Januar 2005 21:25 schrieb Harald Krammer: hi ! I have running some debian/woody machines with kernel 2.4.18. blocked@blocked:~$ cat /proc/version Linux version 2.4.18-1-k7 ([EMAIL PROTECTED]) (gcc version 2.95.4 20011002 (Debian prerelease)) #1 Wed Apr 14 19:20:42 UTC 2004 I saw the last security fix was DSA-479-1 ( long ago) - is it better to switch to 2.4.29 or exits new kernels with all security pachtes ? Kernel 2.4.18 seems to have left the planet due to extraterrestrial commitments. Please use sid's kernel packages instead. Keep smiling yanosz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CAN-2005-0001, CAN-2004-1235, CAN-2004-1137, CAN-2004-1016, Georgi Guninski security advisory #72, 2004, grsecurity 2.1.0 release
Greetings, Am Donnerstag, 13. Januar 2005 10:06 schrieb Christophe Chisogne: Jan Lühr a écrit : Do you recommend to use kernel-source-2.4.27 from sid (sarge) instead of 2.4.18 from woody? On a production server, I would run 2.4, not 2.6. m2 And as Debian security support seems better now for the 2.4.27 kernel, I would choose it. It include fixes backported from kernel.org 2.4.28, even 2.4.29-rc1 Thanks. Ex CAN-2004-1235 (uselib) is fixed since 2.4.29-rc1 at kernel.org and will be fixed soon by upcoming (Debian) kernel-source-2.4.27-8 (and kernel-image-2.4.27-xyz build from it) Sounds good. Will kernel-source-2.4.27 be available in days or weeks? Or you can pick any kernel you want from kernel.org and build one yourself, either the traditional (make config; make dep...) or the Debian way (make config; make-kpkg -- via kernel-package). With the latter (debian), you obtain a debian package for your custom kernel. But that mean you become the local kernel/security maintainer. You can avoid this burden by simply using Debian kernel packages released by the kernel and security teams. Well, running an rc-/pre-release on a production server is quite risky. Btw. AFAIK kernel.org recommend not using their kernels, because they give no security support. Is all information available For my basic needs on this, I often use Google and the 2 links belows For infos about fixes in Debian 2.4.27 kernels, read changelogs in kernel-source-2.4.27 package, by example -- by ex near end of http://packages.debian.org/unstable/devel/kernel-source-2.4.27 For infos about fixes in kernel.org 2.4 kernels, read changelogs and changesets on the kernel.org homepage Thanks. Using kernel-source.2.4.24 from seems to be a good option. Can the openwall / grsecurity patches be applied to kernel-source-2.4.27? Keep smiling yanosz
CAN-2005-0001, CAN-2004-1235, CAN-2004-1137, CAN-2004-1016, Georgi Guninski security advisory #72, 2004, grsecurity 2.1.0 release
Greetings, things seem to be in a rush right now, and I'm looking for a little overview. In the past 1-2 months several kernel exploits rushed through the news that might / can / probably will affect debian stable. However, I haven't seen any signle DSA regarding the following issues: Can you please give me an overview: Which problems do affected kernel-source-2,4.18? - If so, what is the current status of the according DSA? Because of running an terminal-Server I'd like to know, what's going on at these issues. Thanks in advance, Keep smiling yanosz CAN-2005-0001 Linux kernel i386 SMP page fault handler privilege escalation: http://www.isec.pl/vulnerabilities/isec-0022-pagefault.txt (I'm not runnig SMP ;) CAN-2004-1235 Linux kernel uselib() privilege elevation http://isec.pl/vulnerabilities/isec-0021-uselib.txt (Sounds scary PoC Code is included, seems to be discussed here) CAN-2004-1137 Linux kernel IGMP vulnerabilities (Sounds really scary. Are we effected? Debian Woody seems to be uneffected, but what about sarge / sid?) http://isec.pl/vulnerabilities/isec-0018-igmp.txt CAN-2004-1016 Linux kernel scm_send local DoS http://isec.pl/vulnerabilities/isec-0019-scm.txt Georgi Guninski security advisory #72, 2004 Fun with the linux kernel (2.6,2.4) http://www.guninski.com/where_do_you_want_billg_to_go_today_2.html grsecurity 2.1.0 http://www.derkeiler.com/Mailing-Lists/securityfocus/bugtraq/2005-01/0070.html gives on scary / FUD-ish view on the linux kernel. Without discussing their thesis in detail, are patches available? Is kernel-source-2.4.18 affected? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CAN-2005-0001, CAN-2004-1235, CAN-2004-1137, CAN-2004-1016, Georgi Guninski security advisory #72, 2004, grsecurity 2.1.0 release
Greetings, Am Mittwoch, 12. Januar 2005 18:27 schrieb Sam Morris: Jan Lhr wrote: Greetings, things seem to be in a rush right now, and I'm looking for a little overview. In the past 1-2 months several kernel exploits rushed through the news that might / can / probably will affect debian stable. However, I haven't seen any signle DSA regarding the following issues: Can you please give me an overview: Which problems do affected kernel-source-2,4.18? - If so, what is the current status of the according DSA? Because of running an terminal-Server I'd like to know, what's going on at these issues. Add CAN-2004-0554 as well--bug #261521 has been open against kernel-image-2.4.18-1-i386 (but not against kernel-image-2.4.18-i386) since July wish no updates. Uhoh. I tend to use 4-letter words, but this would be highly inappropriate. If it's true, can someone from the official security / kernel team post an official statement on this issue, please? It was scared, when I saw a CAN Id from 1999 in 2004 when a squid bug was fixed, but this quite serious. But anyway, it's not my point to critize the work of the teams. I don't know how to fix it, I don't the reasons for not fixing it already. @who-ever-is-in-charge-with this. Please state your reasons and give a view on comming DSAs. I believe someone posted here a few months ago asking about the bug, and was told that updates were being prepared--but that has not yet happened. :( Release Sarge! - and I will switch to testing using the freebsd kernel. Hopefully, things are not that mad then :-( keep smiling yanosz
Re: CAN-2005-0001, CAN-2004-1235, CAN-2004-1137, CAN-2004-1016, Georgi Guninski security advisory #72, 2004, grsecurity 2.1.0 release
Greetings, Am Mittwoch, 12. Januar 2005 20:32 schrieb Joey Hess: Jan Lühr wrote: things seem to be in a rush right now, and I'm looking for a little overview. In the past 1-2 months several kernel exploits rushed through the news that might / can / probably will affect debian stable. However, I haven't seen any signle DSA regarding the following issues: Can you please give me an overview: Which problems do affected kernel-source-2,4.18? - If so, what is the current status of the according DSA? I'm afraid that I can only tell you the status of 2.6.8 and 2.4.27 in unstable/testing. AFAIK there have not been DSAs for any of these to fix stable, and I don't know which ones really affect stable. Probably most of them. Some of the information below may be incorrect, the kernel team knows better than I. (...) Interesting and helpful information not quoted for better reading. A few others you left out: Thanks for your help, the topic is quite wide-spreded, and I'm a part time network administrator.. Do you recommend to use kernel-source-2.4.27 from sid (sarge) instead of 2.4.18 from woody? CAN-2004-1337 Apparently only affects 2.6, we're not very vulnerable since the module is loaded by the initrd. Not yet fixed. CAN-2004-1335 Fixed in kernel-source-2.6.8. 2.4 is not fixed. CAN-2004-1234 Does not affect sarge since we have a kernel 2.4.25. CAN-2004-1191 Should not affect our 2.4 kernel since it was fixed in 2.4.27. Probably our 2.6.8 kernel is vulnerable. CAN-2004-1190 Could be SuSE specific, unclear and not enough info. CAN-2004-1151 My notes indicate that this was fixed in svn at some point, but I can't find the fix now. CAN-2004-1144 Amd64 specific, don't know if we're vulnerable. CAN-2004-1074 Fixed in kernel-source-2.6.8 2.6.8-11, kernel-source-2.4.27 2.4.27-7, and te binary packages uild from them. CAN-2004-1073 CAN-2004-1072 CAN-2004-1071 CAN-2004-1070 2.6.8 and 2.4.27 are not vulnerable to these. CAN-2004-1069 Only affects 2.6. Fixed in kernel-source-2.6.8 2.6.8-11. CAN-2004-1068 Fixed in kernel-source-2.4.27 2.4.27-7, kernel-source-2.6.8 2.6.8-11. CAN-2004-1058 AFAIK it's unfixed. CAN-2004-1056 Fixed in kernel-source-2.4.27 2.4.27-8 (not yet released), kernel-source-2.6.8 2.6.8-11. CAN-2004-1017 Unknown. CAN-2004-1016 Fixed in kernel-image-2.4.27-i386 2.4.27-7. CAN-2004-0949 Fixed in 2.4.27, but 2.6.8 may still be vulnerable. CAN-2004-0887 s390 specific. Fixed in linux-kernel-image-2.6.8-s390 2.6.8-3, kernel-source-2.6.8 2.6.8-10 CAN-2004-0883 Unknown. CAN-2004-0814 Fixed in kernel-source-2.6.8 2.6.8-8, kernel-source-2.4.27 2.4.27-7 CAN-2004-0813 Fixed in recent 2.6 and 2.4 kernels. CAN-2004-0685 Unknown. CAN-2004-0596 Unknown. CAN-2003-0465 May be unfixed in our 2.4.27 kernel on some arches (bug #280492) i386 and ppc32 are ok. 2.6 fixed. Thanks for your help. I'll look for information on this tomorrow. Is all information available, (as far as I need 'em to check whether it concerns me) or is it kept under disclosure? Keep smiling yanosz
Fwd: dhcp-2 Security Announcement
Greetings, just asking, cause it is relevant for me: Will there be new official stable packages in the next few days (3-4)? (If not, I've to patch it by myself) Keep smiling yanosz ---BeginMessage--- *** From dhcp-announce -- To unsubscribe, see the end of this message. *** Debian has recently distributed a security advisory on the dhcp-2.0pl5 package they distribute. You can read about that here: http://www.debian.org/security/2004/dsa-584 The following versions of ISC DHCP are vulnerable: dhcp-2.0: All versions are vulnerable. dhcp-3.0: dhcp-3.0b1pl17 and previous versions are vulnerable. All users of these versions should upgrade to the latest dhcp-3 release, currently dhcp-3.0.1. Note: If for some reason upgrading from dhcp-2 is not possible, you may also consider applying this patch: ftp://ftp.isc.org/isc/dhcp/dhcp-2.0-history/dhcp-2.0pl6.patch ftp://ftp.isc.org/isc/dhcp/dhcp-2.0-history/dhcp-2.0pl6.patch.asc But users are strongly advised to make the upgrade to dhcp-3 now. -- David W. HankinsIf you don't do it right the first time, Operations Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins --- To unsubscribe from this list, visit http://www.isc.org/dhcp-lists.html or send mail to [EMAIL PROTECTED] with the subject line of 'unsubscribe'. --- ---End Message---
Re: Fwd: dhcp-2 Security Announcement
Greetings, Am Dienstag, 9. November 2004 21:44 schrieb Bartosz Fenski aka fEnIo: On Tue, Nov 09, 2004 at 09:28:34PM +0100, Jan Lühr wrote: just asking, cause it is relevant for me: Will there be new official stable packages in the next few days (3-4)? (If not, I've to patch it by myself) Please read that announcement more careful. It is fixed in stable already. thanks, I misunderstood the adv somehow. It seemed to me like there has been an issue fixed in debian, but after reading, I thought there has been another issue. My apologies. Keep smiling yanosz
Re: Security issue? Daemon users has to much rights...
Greetings,... Am Samstag, 23. Oktober 2004 00:36 schrieb Michael Stone: On Fri, Oct 22, 2004 at 11:13:55PM +0200, Jan Lühr wrote: Of course, providing security on that level is not the best way to ensure the system's integrity and safety. But why do you think, that security on filesystem level is doomed to failure if it's part of a security concept? Because you haven't described a practical approach for implementing allow all the users except lp to access mount in a way which works for naive system administrators. What do you expect here? Of course there is a tradional unix approach (groups -ugly one I admit - and a more clean approach using posix acls). If defaults are setted in a senseful way, you can protect suid binaries from being used by the wrong users. What's wrong in that idea? As long as you grant right's - related to suid - on filesystem level, it's useful to restrict them on this level, too. Sudo is another approach, but sudo makes things even more complicated. Do you think, deleting all root-suid bits and using sudo i a better approach for naive admins? Keep smiling yanosz
Re: Security issue? Daemon users has to much rights...
Greetings,... Am Samstag, 23. Oktober 2004 05:58 schrieb Daniel Pittman: On 23 Oct 2004, Jan Lhr wrote: Am Freitag, 22. Oktober 2004 14:02 schrieb Daniel Pittman: On 22 Oct 2004, Jan Lhr wrote: Yes, and that is one of the core points in my suggestion that you look at SELinux or a similar mandatory access control based security module. SELinux is overkill in some ways. A system adminstrator, not being able to handle ACLs won't be able to handle SELinux. [...] Of course not. But on the other hand, there are parts of the system, a deamon user should not be able to stick his nose in. Imho a more restrictive way is necessary. MAC allows you to actually enforce these rules, rather than simply making it a bit harder or the mechanism a bit more obscure. As people have been saying for years, security through obscurity is no real security at all -- and preventing access to on-disk binary code does not prevent access to the risky areas. Well, standard debian binary code is available for nearly everyone. Sec-by-obs by setting fs-rights was not in my intention. [...] I think that trying to enforce this sort of security at the filesystem level is doomed to failure, as it is the wrong level to work at. Ok, but why should lp (as user) be able to access mount (suid)? I see no reason to allow them to do so, but I see many reasons for not allowing them to do so. They shouldn't be able to access mount, or related functionality. Trying to enforce that through filesystem permissions is a task that has a large number of failure points, especially in the face of multiple vulnerabilities. Of course. But even chrooting everything was exploited in past. If you are a victim of multiple vulns - god bless you. One of the most common failures for this sort of security is a copy of the binary accessed through another path name, etc, that allows the undesired code to be executed despite protection in of the main copy. If a file can be accessed through some link, loading, etc. tricks sec. on fs-level is not implemented correctly. Without taking control over kernel-functions (like root-kits do, but you have to be root to do so) no one should be able to bypass the file-system layer. The best example for this is mounting partition's noexec. Everyone, who has sticked is nose into that topic is able to bypass this flag, but programs like dpkg are not able to do there work, if /tmp is mounted noexec - strange world. If the non-execution idea was implemented correctly neither this bypass nor any other would be possible. (I'd like to append, that Imho the current linux kernel / userland architecture is unable to allow a clean implementation of this). Also, trying to define the security rules at the filesystem level provides no real protection against many locally exploitable holes. Many of these can be accessed by talking over network sockets or other channels than the filesystem. If you gain root, everything is possible on a root centric-system. Using non-root-centric systems is tending to confuse naive admins. If you want to achieve this sort of high level security by default, consider finding and working with the people who are trying to provide the tools and environment required to run SELinux, or some other MAC implementation, in Debian. NSA is evil by default ;-) The code is all out there; feel free to audit it. ;) Well, I've some other work to do in the next months. ;-) Alternatively, trust some other group who write LSM code to implement a MAC system, or even one of the alternative security models, and work on getting that into Debian as an option or, eventually, by default. I named SELinux because I know there to be a real effort to get this working out of the box, not because I have any special love for it. Well, yeah. But peopple who developed trojan horses like magic like magic latern are not trustworthy in my opinion. ;-) Of course, providing security on that level is not the best way to ensure the system's integrity and safety. But why do you think, that security on filesystem level is doomed to failure if it's part of a security concept? The introduction of shadow passwords use the concept of file system level security. Imho allowing $daemon to access $some-unnecessary-suid-binary is doomed to failure. You may note that the shadow password system has also moved on, to include other methods for encrypting the password since, at the end of the day, these filesystem permissions can be bypassed. :) Of course, at the end of these days, even bypassing of chroot and vmware is documented. You are right when you say that using filesystem permissions can provide some measure of additional security, and when you say that the introduction of an ACL capability into many common filesystems in Linux opens the door to enabling this. Between the complexity of the ACL system, the difficulty in defining security rules for a
Security issue? Daemon users has to much rights...
Greetings, because of the recent xpdf issues I tested the access restrictions of some users like lp, mail, etc. with default settings in sarge. I noticed that, by default, no acl were used to prevent access to vital system commands, the user shouldn't have. For instance: lp could mount a vfat partion marked as user mountable in fstab, execute df or mount to gain information about the systems topology. By introducing acl's in late 2.4 and 2.6 (both are the main kernel branches for sarge and are used during the installaion), it might be worth the effort to introduce default ACLs during the installation process (optional of course) in order to protect systems not managed by skilled admins. (rentable server, etc.) What do you think? Who's in charge with this decision? Keep smiling yanosz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Security issue? Daemon users has to much rights...
Greetings, Am Freitag, 22. Oktober 2004 14:02 schrieb Daniel Pittman: On 22 Oct 2004, Jan Lhr wrote: because of the recent xpdf issues I tested the access restrictions of some users like lp, mail, etc. with default settings in sarge. I noticed that, by default, no acl were used to prevent access to vital system commands, the user shouldn't have. For instance: lp could mount a vfat partion marked as user mountable in fstab, execute df or mount to gain information about the systems topology. I don't think that you understand what an ACL, or Access Control List, is -- or, possibly, you have learned an uncommon use of that terminology elsewhere. Access Control Lists are almost always used in the context of extended filesystem permissions, as a way of granting or revoking more than the simple user/group/other spilt traditional to Unix. sure. They are not the usual technology used to provide access partitioning to the system in the style you suggest above, although they can in some cases make it easier to implement that sort of security policy. Of course. This is, in large part, because preventing access to the binaries commands on disk does little or nothing to prevent a determined attacker from gaining the equivalent functionality through directly calling the kernel. That's true as well. But the binaries are just an example for unnecessary rights. Even preventing them from having access to libc doesn't really help much. :) Of course not. But on the other hand, there are parts of the system, a deamon user should not be able to stick his nose in. Imho a more restrictive way is necessary. For instance access to the mount command is not that critical, but hijacked daemons (take a hijacked cups for instance) allow to use local root exploits, a remote attacker would never have been able to. Forgotten suid-binaries are a great risk. By introducing acl's in late 2.4 and 2.6 (both are the main kernel branches for sarge and are used during the installaion), it might be worth the effort to introduce default ACLs during the installation process (optional of course) in order to protect systems not managed by skilled admins. (rentable server, etc.) What do you think? I think that trying to enforce this sort of security at the filesystem level is doomed to failure, as it is the wrong level to work at. Ok, but why should lp (as user) be able to access mount (suid)? I see no reason to allow them to do so, but I see many reasons for not allowing them to do so. If you want to achieve this sort of high level security by default, consider finding and working with the people who are trying to provide the tools and environment required to run SELinux, or some other MAC implementation, in Debian. NSA is evil by default ;-) Of course, providing security on that level is not the best way to ensure the system's integrity and safety. But why do you think, that security on filesystem level is doomed to failure if it's part of a security concept? The introduction of shadow passwords use the concept of file system level security. Imho allowing $daemon to access $some-unnecessary-suid-binary is doomed to failure. Who's in charge with this decision? I don't think you could succeed in having this imposed by fiat on the Debian project, especially at this late stage, since it would be a huge level of work. Well, yes. Sid might be a target as well. Keep smiling yanosz
Re: CAN-2003-0020?
Greetings, Am Sonntag, 18. April 2004 18:56 schrieb Matt Zimmerman: On Sat, Apr 17, 2004 at 10:16:11PM +0200, Jan L??hr wrote: what about http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0020 ? Is debian finally going to fix it? Current consensus between the security team and the Apache maintainers is that it is not necessary to fix this in woody. Ehm... why ? ;) What about sarge or sid? Keep smiling yanosz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CAN-2003-0020?
Greetings, Am Sonntag, 18. April 2004 18:56 schrieb Matt Zimmerman: On Sat, Apr 17, 2004 at 10:16:11PM +0200, Jan L??hr wrote: what about http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0020 ? Is debian finally going to fix it? Current consensus between the security team and the Apache maintainers is that it is not necessary to fix this in woody. Ehm... why ? ;) What about sarge or sid? Keep smiling yanosz
CAN-2003-0020?
Greetings, what about http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0020 ? Is debian finally going to fix it? keep smiling yanosz
Re: [SECURITY] [DSA 479-1] New Linux 2.4.18 packages fix local root exploit (source+alpha+i386+powerpc)
Greetings, Am Mittwoch, 14. April 2004 23:08 schrieb Phillip Hofmeister: If you checked the reference CVE numbers you should be able to tell when the exposure first occurred (or close to it). Thanks :) - I have already been there. Are there any, no longer classified information about the fixing process? Keep smilling yanosz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 479-1] New Linux 2.4.18 packages fix local root exploit (source+alpha+i386+powerpc)
Greetings, Am Mittwoch, 14. April 2004 23:08 schrieb Phillip Hofmeister: If you checked the reference CVE numbers you should be able to tell when the exposure first occurred (or close to it). Thanks :) - I have already been there. Are there any, no longer classified information about the fixing process? Keep smilling yanosz
Re: [SECURITY] [DSA 479-1] New Linux 2.4.18 packages fix local root exploit (source+alpha+i386+powerpc)
Greetings, Am Mittwoch, 14. April 2004 16:52 schrieb Martin Schulze: -- Debian Security Advisory DSA 479-1 [EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze April 14th, 2004http://www.debian.org/security/faq -- Package: kernel-source-2.4.18 kernel-image-2.4.18-1-alpha kernel-image-2.4.18-1-i386 kernel-image-2.4.18-i386bf kernel-patch-2.4.18-powerpc Vulnerability : several vulnerabilities Problem-Type : local Debian-specific: no CVE ID : CAN-2004-0003 CAN-2004-0010 CAN-2004-0109 CAN-2004-0177 CAN-2004-0178 puh - synchronised with the realese 2.4.26 and no warnings of bugtraq or fd... Good work. I imagine that everything is fixed in 2.4.26. Does someone know if 2.4.26 is a bugfix pre-release? I'm getting a little bit confused right know, if there are serious issue with the kernel, why wasn't there any earlier release of 2.4.26? Refering to the large number of fixed vuln, might an earlier release of single patches has been an option? Or did you watch fd to find the right time? Keep smiling yanosz
Re: [SECURITY] [DSA 479-1] New Linux 2.4.18 packages fix local root exploit (source+alpha+i386+powerpc)
Greetings,.. Am Mittwoch, 14. April 2004 20:57 schrieben Sie: Jan Lühr [EMAIL PROTECTED] writes: Greetings, Okay... This is the result of a cursory check, do your homework, yada, yada... Thanks for doing so ;) Anyway, this wasn't the intetention of my post. My point is, that five local root exploits at once are a little bit scary, as far as there are no patch- days for debian ;). So I'd like to know, which of them might have been fixed earlier. It's just my interest to track the linux-sec-efforts from my point of view. Keep smiling yanosz
Re: Known vulnerabilities left open in Debian?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Greetings,
Am Montag, 22. März 2004 19:30 schrieb Sven Hoexter:
On Mon, Mar 22, 2004 at 06:57:39PM +0100, Giacomo Mulas wrote:
There is a \begin{sarcasm} nice \end{sarcasm} article in
linuxworld Australia (see
http://www.linuxworld.com.au/index.php/id;1607539824;fp;2;fpid;1) which,
among other things, claims that Debian (Debian GNU/Linux) has left
vulnerabilities there and didn't release any patches for them.
Imho this article is about 90% percent correct - 95% percent if you ignore the
marketing waste.
5% not, because the article put specific facts into general. The debian
distribution in whole is an easy target for hackers. The point is: If you
want to built a secure operating system you have to know exactly what you are
doing. What are the current vuln of the program I'm currently installing?
What do I have to do to work around them? Are there any known bugs? What does
the changelog say about these version? Have all fixes been backported to
debian?
The mozilla problem is one of the best examples what debian is into. If you
trust in the ability of the debian project to release a secure distribution
you are a fool!
But the point is: what's the alternative? If $big_fat_distributer is crippled
by its own release policy or profit making intention - they will _NEVER_ be
secure.
Debian might be more secure, if they recognise, that security gathered
importance.
btw. There was / is / won't be any absolutly secure operating system, covering
the needs of an ordinary modern server.
Well a week ago or so we had a longer discussion here about open bugs left
in the ancient mozilla version in woody.
discussion without conclusion I must admit - sadly.
It might be to necessary to file as many rc-bugs to the current packages
(mozilla, cron e.g.) as possibly. Thus debian-sarge might never be releases
(who want to release sarge with 1000-2000 sec. bugs - it might be worth the
effort).
It it's done that way, the leadership of the project will have to decide,
whether they want to ignore sec. aspects and release sarge by as many
laughter as neccessary or change the release policy or never release sarge.
Sadly - I don't have access to secret information (cve, etc.) which would be
needed to do so.
That's the only example I know but that doesn't mean much.
Cron is another example - the be honest, the debian security team seems to be
crippled by the debian release policy.
Because of this policy debian stable is insecure by definition.
Regards
J.Luehr
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)
iQIVAwUBQF9FLNAHMQ8GQaYRAQKGGg//ROiiYIX/3ttelj+58StXXwwS0Kkpfps5
GK3eVIiG/BIjR/VNnH9gVYVU9pEL/ot/S/8t9Bd3V4Bv/rPKacfeNUuulRwRo8Su
Nh8gochz0KQl/FQbr853VGgbBcCg/CCEJPeqtYwpxHqEXgkfYA0xQcYkRdRKZ+nd
IKYacu2aqqF1cfFt4A9bhi67pR2byzJn8U8SN0iBL/lkGSlq5GjMuUwxDzqfqar8
ZeuCTFeTGiL9ftNJQV1YpnM3U/Ya3Wx64E3tYG2+HfKl1AvSmz2rmz8QpHQi2tPm
5oxTQ80yYDqJW4FSrPXt0cSVsYLZjGo0IZif64kBEb39K/tLlLkG+HrLdS+8uPuM
AwR83aBg3MNHbNtYo/nPF3OqWGbOzyUvtmESZlBsEesgeZNEFjt91qkk/GFNfOBA
uJhw63VvzPXZSvuKkRtsWS+nx2VEODYNoUmFER0ZOZQXc+mslTEBoiODbB3JgA8A
tlYt5egSXh0ULCGPqqgVvF60F4T+yFxp2yjyHmVdWm6gBTu8d2rTr5sUukkLqRwC
7MRc1uMdL/XM4I5+nUwhA2DhCywEPjmDt1UpHdk+hvzDO9ybp8IzvwMVw+yMV51G
HPOemUBwlgXxPE0fNJ5KgwUmmxUb6VUVddfLBCK0xCijksS9+T/L0o8SUt0Yi8yW
zfwAI+1dgcU=
=VFzq
-END PGP SIGNATURE-
Re: Known vulnerabilities left open in Debian?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings,... Am Montag, 22. März 2004 21:05 schrieb Matt Zimmerman: On Mon, Mar 22, 2004 at 08:57:26PM +0100, Jan L?hr wrote: Cron is another example Cron is another example of what? By all means, please elaborate. Of a package of the discussed categorie. - the be honest, the debian security team seems to be crippled by the debian release policy. Because of this policy debian stable is insecure by definition. If you have concrete information about unfixed bugs, bring it forth. Otherwise this is just more FUD. Moz bug 228176 [1] is an example. Keep smiling yanosz [1] http://bugzilla.mozilla.org/show_bug.cgi?id=228176 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iQIVAwUBQF9QU9AHMQ8GQaYRAQK4LRAAiGzERvEsWzhVZQyipGRmS1NguwKEpi/M 78sGIya2VDcgrsyGquRloQn9xdEI5iIVZcVqj8QLXUw05B5K76Qdym87/uzS6px1 BjyccCtERxgISkjLKVB+CK8pfzl9K+lTOkMHPHFcfWo5dUtqp3nVBjXxGgXABKix hGhsODxXMsmPk3IsW7xyAquUeRMs/NrDRRNNGwfTryMRFS6CO2g2OjBBnq17HKap 9ZYCcEhmZO226I8g4uL8tPSo+Dxt+l0Eirh2exhTsMuuLZj9N8Tqtx5owEW41KoN SEr1rjDC5a7Jv9jJfChRnc/dpNbuwn5A+lavk9cJI9WD0SE7W1Zc3+W71gh/M9RQ RBezUlNPi58+dE8A7weElyO3rnqZexNYvcm+3wF5Gj7+I1zQUz4f4A4IFYWH7q0q Xt0gxAmVVcZAwrZrBXcAAijw0P3MfavxNpDUq9cs8t6SI9Canv63uEgqyflrgxUL nEzfMFbi5ndeRyi+gRz5MSzbJId+5sjL9rNkkgdzyBlgyzb7sBsq4UdKZyD8IWnK pj9Fc94WiSsWk0WbUoCECdUlbhJIW77NY7JiH6GcjFr3mo4vTh90nnHcAVhgjkIh 8oIfObG9LalWkjbc/zk26xx3xLK58j9F+NwAXSrzkCCV5JiO5TbUl2KyQHN59MpJ DL0/E5wKDk4= =NRUA -END PGP SIGNATURE-
Re: Known vulnerabilities left open in Debian?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings, Am Montag, 22. März 2004 21:52 schrieb Ramon Kagan: Every so often another set of tirades goes across this list. So I wish only to give my 2 cents. 1. If you don't like the way debian conducts it's FREE business, my opinion is go find another volunteer group to haggle. ehem. What about critics? Am I not allowed to critices their work? As I have pointed out, their is no alternative for it. But the point is: what's the alternative? If $big_fat_distributer is crippled by its own release policy or profit making intention - they will _NEVER_ be secure. I said. So the debian security team is doing a good job at the whole. 2. If you are going to complain about something you don't like, then either be constructive about it, i.e. say this could be fixed by ... or can I help in some way..., or just stop wasting my time and others on this list. I made my suggestions how to fix it. 3. Debian is a testament to the ability of a VOLUNTEER system working across multiple countries and continents to provide a good service. Is it perfect? Probably not, but I haven't found a paid service that is either. Remember you are not a paying customer, so what right do you have in complaining in not constructive matter? 100% ACK. 4. I would like to thank all the volunteers in the Debian organization for all the hard work they do to make my life easier and more productive. You all deserve KUDOS. m2. As for the complainers, either shape up or ship out, we never asked you to use the product. Go get yourself a copy of RedHat and see how wonderful their product is. Well, I pointed out that there is not real alternative. Imho the current release policy doesn't support the creation of a secure distribution. Keep smiling yanosz -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iQIVAwUBQF9c4dAHMQ8GQaYRAQLqPA//cFN7DgJ7NPljQTPlT6p1qYFo3xr2bosK N4lNbVkaJQt33IcYwpSBn0HlIBfr0CEpHQeuKy6mFobGvHNggzIHH0ulfhAeIGX+ cU9wSS4QGhhrvxPnU3MF5DnKzgBPVo13jxDRBBjmjyp5xyoE2/AQMJ+nEyqxtWF7 uWYczepYv4cGzsDRcHgskAq6n65Cng5wOQyMdLOpCJES1hFum+i2dj0VPYFNUsuI UOp+r8QX4k6gSJUxlYwJ6zDURm7YQPLo1D24KBazUc37WdpHxs3uOOVFmGL1Pe5k UXxfffE59ed63rNJDBBRFp+IsSiPwWBjhs5fZxRJ3Il0fB6fQBXqv5qTXlQSbazL u1tm4rcxQLApO+gGhxjwU5BKQAEtLj9TaPWKzzVppdpHn9K+WSFF3pSlkAZCSEvF Qm89wRELroof6tPn6nBI11MMG45fOeeBMMys3mfjQhoIx1hV+1p2t4SgteRAfCDp sgtm4WqgXWrGvcO0PG6PLz9/j+UaGU6qetVCwg/rMaEf3aByZXplqw2aJMxzJfrW KNcJ0knE7X/Eymo9ewQnoZzcHnF3uHsSA0QXNc5wwh5EORsuV29pFIwu0+RLwCY6 1t5vzTXXA3xTp+NYi8qUHft+9SF0IkaBd4rNmCbQboNAof5LvsuQvdp/mDmUwiOn 9AQaXWZbAQU= =QBQS -END PGP SIGNATURE-
Re: Known vulnerabilities left open in Debian?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings, Am Montag, 22. März 2004 21:20 schrieb Nathan Eric Norman: On Mon, Mar 22, 2004 at 10:01:14PM +0100, Jan Lühr wrote: Greetings, Am Montag, 22. März 2004 21:16 schrieb Bryan Allen: On Mar 22, 2004, at 2:57 PM, Jan Lühr wrote: Cron is another example - the be honest, the debian security team seems to be crippled by the debian release policy. Because of this policy debian stable is insecure by definition. http://security.debian.org/ You are asked on install if you would like to use it. The default is yes. irony I did so, but I didn't get all necessary patches - did I do something wrong? /irony You opened a bug on cron and supplied links to the patches you're talking about, right? For some reason I don't see any open bugs on cron with your name on them. Sorry, there was a misunderstanding between Florian and me (in a previous e-mail correspondence). I'd like to cancel my statements about cron - my apologies. Keep smiling yanoszu -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iQIVAwUBQF9eqtAHMQ8GQaYRAQLh6hAAnDcBcOT/bn31OTvtgzibj26bOQgP22Q5 j93+L0+odxV1FKjLFiE3vsAAaBzut8Px5/9r84yHUNm/LfPhPJWlASrtsXbG9S9Z 4FO8FkQWR6/lj1ejpqRK7aGUAEsb7jwDzJbcXKwzNrtK56BekSxClRatXc8B6nL9 x3MDvrV0coYDXTF7zTezAP4xaWbuzcBwdUOQu41HsxvYRbUy1jNeO9lCeNXQWn2M tjTlKibzRHNQJd6Cao/JWhN4ZObdYFW1GqJCNl3ZnmN0PZptr0TlCABlstDH9Z3s 16vWs+lk0nyctM0yyYtkSiKaw8XMMkiZAgixkvP0s9MEUsEKz9fXM+cW9juv38Pf 1mRDLeQwF+KCDeF2cBzT5Q24YRypzLbEoqoZBMFhY0HnDdi1V7/B1vm3tprchz+Q eWcKdlJ8uM1LPMNDMOlM5W1tyI34ZAnVuo9etgOeUCFgSFa6I25Cj+ZiY0m5kyER 6mIELZixHzQHv33QC4e3zGU5vJPjNAwMic6wSB/aThy1hUxAQHp1Mu2qeBokigZN jC5xvwohEb0kLkK/izfvUz6mMH3kkSVjU4dbHP4Eni4OjAH23UnVVnqafQnpz3ni 4fJTfGNWPPQeAtVaov2Jg/ashwO0OeEh83kFmWoxedgLVOFkRRGcTiRHdfhFwzMh 7yivSHXY+G8= =v8DJ -END PGP SIGNATURE-
Re: Known vulnerabilities left open in Debian?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Greetings,
Am Montag, 22. März 2004 19:30 schrieb Sven Hoexter:
On Mon, Mar 22, 2004 at 06:57:39PM +0100, Giacomo Mulas wrote:
There is a \begin{sarcasm} nice \end{sarcasm} article in
linuxworld Australia (see
http://www.linuxworld.com.au/index.php/id;1607539824;fp;2;fpid;1) which,
among other things, claims that Debian (Debian GNU/Linux) has left
vulnerabilities there and didn't release any patches for them.
Imho this article is about 90% percent correct - 95% percent if you ignore the
marketing waste.
5% not, because the article put specific facts into general. The debian
distribution in whole is an easy target for hackers. The point is: If you
want to built a secure operating system you have to know exactly what you are
doing. What are the current vuln of the program I'm currently installing?
What do I have to do to work around them? Are there any known bugs? What does
the changelog say about these version? Have all fixes been backported to
debian?
The mozilla problem is one of the best examples what debian is into. If you
trust in the ability of the debian project to release a secure distribution
you are a fool!
But the point is: what's the alternative? If $big_fat_distributer is crippled
by its own release policy or profit making intention - they will _NEVER_ be
secure.
Debian might be more secure, if they recognise, that security gathered
importance.
btw. There was / is / won't be any absolutly secure operating system, covering
the needs of an ordinary modern server.
Well a week ago or so we had a longer discussion here about open bugs left
in the ancient mozilla version in woody.
discussion without conclusion I must admit - sadly.
It might be to necessary to file as many rc-bugs to the current packages
(mozilla, cron e.g.) as possibly. Thus debian-sarge might never be releases
(who want to release sarge with 1000-2000 sec. bugs - it might be worth the
effort).
It it's done that way, the leadership of the project will have to decide,
whether they want to ignore sec. aspects and release sarge by as many
laughter as neccessary or change the release policy or never release sarge.
Sadly - I don't have access to secret information (cve, etc.) which would be
needed to do so.
That's the only example I know but that doesn't mean much.
Cron is another example - the be honest, the debian security team seems to be
crippled by the debian release policy.
Because of this policy debian stable is insecure by definition.
Regards
J.Luehr
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)
iQIVAwUBQF9FLNAHMQ8GQaYRAQKGGg//ROiiYIX/3ttelj+58StXXwwS0Kkpfps5
GK3eVIiG/BIjR/VNnH9gVYVU9pEL/ot/S/8t9Bd3V4Bv/rPKacfeNUuulRwRo8Su
Nh8gochz0KQl/FQbr853VGgbBcCg/CCEJPeqtYwpxHqEXgkfYA0xQcYkRdRKZ+nd
IKYacu2aqqF1cfFt4A9bhi67pR2byzJn8U8SN0iBL/lkGSlq5GjMuUwxDzqfqar8
ZeuCTFeTGiL9ftNJQV1YpnM3U/Ya3Wx64E3tYG2+HfKl1AvSmz2rmz8QpHQi2tPm
5oxTQ80yYDqJW4FSrPXt0cSVsYLZjGo0IZif64kBEb39K/tLlLkG+HrLdS+8uPuM
AwR83aBg3MNHbNtYo/nPF3OqWGbOzyUvtmESZlBsEesgeZNEFjt91qkk/GFNfOBA
uJhw63VvzPXZSvuKkRtsWS+nx2VEODYNoUmFER0ZOZQXc+mslTEBoiODbB3JgA8A
tlYt5egSXh0ULCGPqqgVvF60F4T+yFxp2yjyHmVdWm6gBTu8d2rTr5sUukkLqRwC
7MRc1uMdL/XM4I5+nUwhA2DhCywEPjmDt1UpHdk+hvzDO9ybp8IzvwMVw+yMV51G
HPOemUBwlgXxPE0fNJ5KgwUmmxUb6VUVddfLBCK0xCijksS9+T/L0o8SUt0Yi8yW
zfwAI+1dgcU=
=VFzq
-END PGP SIGNATURE-
Re: Known vulnerabilities left open in Debian?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings,... Am Montag, 22. März 2004 21:05 schrieb Matt Zimmerman: On Mon, Mar 22, 2004 at 08:57:26PM +0100, Jan L?hr wrote: Cron is another example Cron is another example of what? By all means, please elaborate. Of a package of the discussed categorie. - the be honest, the debian security team seems to be crippled by the debian release policy. Because of this policy debian stable is insecure by definition. If you have concrete information about unfixed bugs, bring it forth. Otherwise this is just more FUD. Moz bug 228176 [1] is an example. Keep smiling yanosz [1] http://bugzilla.mozilla.org/show_bug.cgi?id=228176 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iQIVAwUBQF9QU9AHMQ8GQaYRAQK4LRAAiGzERvEsWzhVZQyipGRmS1NguwKEpi/M 78sGIya2VDcgrsyGquRloQn9xdEI5iIVZcVqj8QLXUw05B5K76Qdym87/uzS6px1 BjyccCtERxgISkjLKVB+CK8pfzl9K+lTOkMHPHFcfWo5dUtqp3nVBjXxGgXABKix hGhsODxXMsmPk3IsW7xyAquUeRMs/NrDRRNNGwfTryMRFS6CO2g2OjBBnq17HKap 9ZYCcEhmZO226I8g4uL8tPSo+Dxt+l0Eirh2exhTsMuuLZj9N8Tqtx5owEW41KoN SEr1rjDC5a7Jv9jJfChRnc/dpNbuwn5A+lavk9cJI9WD0SE7W1Zc3+W71gh/M9RQ RBezUlNPi58+dE8A7weElyO3rnqZexNYvcm+3wF5Gj7+I1zQUz4f4A4IFYWH7q0q Xt0gxAmVVcZAwrZrBXcAAijw0P3MfavxNpDUq9cs8t6SI9Canv63uEgqyflrgxUL nEzfMFbi5ndeRyi+gRz5MSzbJId+5sjL9rNkkgdzyBlgyzb7sBsq4UdKZyD8IWnK pj9Fc94WiSsWk0WbUoCECdUlbhJIW77NY7JiH6GcjFr3mo4vTh90nnHcAVhgjkIh 8oIfObG9LalWkjbc/zk26xx3xLK58j9F+NwAXSrzkCCV5JiO5TbUl2KyQHN59MpJ DL0/E5wKDk4= =NRUA -END PGP SIGNATURE-
Re: Known vulnerabilities left open in Debian?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings, Am Montag, 22. März 2004 21:16 schrieb Bryan Allen: On Mar 22, 2004, at 2:57 PM, Jan Lühr wrote: Cron is another example - the be honest, the debian security team seems to be crippled by the debian release policy. Because of this policy debian stable is insecure by definition. http://security.debian.org/ You are asked on install if you would like to use it. The default is yes. irony I did so, but I didn't get all necessary patches - did I do something wrong? /irony Keep smiling yanosz -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iQIVAwUBQF9UINAHMQ8GQaYRAQJHVhAAkYhW7RGPvMLltPbsHjB1v3YvD/xraXNQ PuTsZxoBFRY2p1uMJ9WMef0lLwLwPLjJ+8lT5yC613sbZH5Oskc9J7+50F3NiMjC zxWMETBstzGxO03FDlCif/7YJ6w4lCMPJbloTpwKGRNyyVp+0udBoUNmwXg62nyy Ek7TdGFsBqGHQaTxWwVNSw8oJB9MtLc2gVZ/OmCxYhiRe9AfWWl9IVZG5UDo18ys FixoahoLlayPpAdbNYJM49KWBxJjntWJ+UnIwCrfnhFpEJlDSdym8JctrMbbWY/1 R4+hwfU5cQY/g8RoSZtqNf4zq+cKI6cyB05s/we5jJ6pIGGRufOTlLT/U6Gy7nok EiPhRCV8+nwvrNOSpjGMGjTLj06T9TgmRcwAhFphbu8mvNJ/7YW2ZIU6OHCEWTSN 0m1+mXVHqGjPcIeDOVWbQ5iWcOgoexGvr/Qn/sNiMXESIXIQ4+AY+YPFPAImA6sm mMWgYaK9uKVJL7pMhAPWBxnBoat7qjzIYLdJ/PTI5Cbj7iiwcXbHejcbO2Tu0Kb/ MKS/Zd5i0PKZTSKkgxaBVJUKhb907nPJf7+aiBYXIkOTsZuceoe6WRTW/rhAUiUB /DJVeYle6KE3SkojAm9xFNDMv3LH6UY2OKD05ypEhOVLBMHgIx+Fm00yfgMwRoT8 VFq884bD1hU= =Vbmb -END PGP SIGNATURE-
Re: Known vulnerabilities left open in Debian?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings, Am Montag, 22. März 2004 21:52 schrieb Ramon Kagan: Every so often another set of tirades goes across this list. So I wish only to give my 2 cents. 1. If you don't like the way debian conducts it's FREE business, my opinion is go find another volunteer group to haggle. ehem. What about critics? Am I not allowed to critices their work? As I have pointed out, their is no alternative for it. But the point is: what's the alternative? If $big_fat_distributer is crippled by its own release policy or profit making intention - they will _NEVER_ be secure. I said. So the debian security team is doing a good job at the whole. 2. If you are going to complain about something you don't like, then either be constructive about it, i.e. say this could be fixed by ... or can I help in some way..., or just stop wasting my time and others on this list. I made my suggestions how to fix it. 3. Debian is a testament to the ability of a VOLUNTEER system working across multiple countries and continents to provide a good service. Is it perfect? Probably not, but I haven't found a paid service that is either. Remember you are not a paying customer, so what right do you have in complaining in not constructive matter? 100% ACK. 4. I would like to thank all the volunteers in the Debian organization for all the hard work they do to make my life easier and more productive. You all deserve KUDOS. m2. As for the complainers, either shape up or ship out, we never asked you to use the product. Go get yourself a copy of RedHat and see how wonderful their product is. Well, I pointed out that there is not real alternative. Imho the current release policy doesn't support the creation of a secure distribution. Keep smiling yanosz -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iQIVAwUBQF9c4dAHMQ8GQaYRAQLqPA//cFN7DgJ7NPljQTPlT6p1qYFo3xr2bosK N4lNbVkaJQt33IcYwpSBn0HlIBfr0CEpHQeuKy6mFobGvHNggzIHH0ulfhAeIGX+ cU9wSS4QGhhrvxPnU3MF5DnKzgBPVo13jxDRBBjmjyp5xyoE2/AQMJ+nEyqxtWF7 uWYczepYv4cGzsDRcHgskAq6n65Cng5wOQyMdLOpCJES1hFum+i2dj0VPYFNUsuI UOp+r8QX4k6gSJUxlYwJ6zDURm7YQPLo1D24KBazUc37WdpHxs3uOOVFmGL1Pe5k UXxfffE59ed63rNJDBBRFp+IsSiPwWBjhs5fZxRJ3Il0fB6fQBXqv5qTXlQSbazL u1tm4rcxQLApO+gGhxjwU5BKQAEtLj9TaPWKzzVppdpHn9K+WSFF3pSlkAZCSEvF Qm89wRELroof6tPn6nBI11MMG45fOeeBMMys3mfjQhoIx1hV+1p2t4SgteRAfCDp sgtm4WqgXWrGvcO0PG6PLz9/j+UaGU6qetVCwg/rMaEf3aByZXplqw2aJMxzJfrW KNcJ0knE7X/Eymo9ewQnoZzcHnF3uHsSA0QXNc5wwh5EORsuV29pFIwu0+RLwCY6 1t5vzTXXA3xTp+NYi8qUHft+9SF0IkaBd4rNmCbQboNAof5LvsuQvdp/mDmUwiOn 9AQaXWZbAQU= =QBQS -END PGP SIGNATURE-
Re: Known vulnerabilities left open in Debian?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings, Am Montag, 22. März 2004 21:20 schrieb Nathan Eric Norman: On Mon, Mar 22, 2004 at 10:01:14PM +0100, Jan Lühr wrote: Greetings, Am Montag, 22. März 2004 21:16 schrieb Bryan Allen: On Mar 22, 2004, at 2:57 PM, Jan Lühr wrote: Cron is another example - the be honest, the debian security team seems to be crippled by the debian release policy. Because of this policy debian stable is insecure by definition. http://security.debian.org/ You are asked on install if you would like to use it. The default is yes. irony I did so, but I didn't get all necessary patches - did I do something wrong? /irony You opened a bug on cron and supplied links to the patches you're talking about, right? For some reason I don't see any open bugs on cron with your name on them. Sorry, there was a misunderstanding between Florian and me (in a previous e-mail correspondence). I'd like to cancel my statements about cron - my apologies. Keep smiling yanoszu -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iQIVAwUBQF9eqtAHMQ8GQaYRAQLh6hAAnDcBcOT/bn31OTvtgzibj26bOQgP22Q5 j93+L0+odxV1FKjLFiE3vsAAaBzut8Px5/9r84yHUNm/LfPhPJWlASrtsXbG9S9Z 4FO8FkQWR6/lj1ejpqRK7aGUAEsb7jwDzJbcXKwzNrtK56BekSxClRatXc8B6nL9 x3MDvrV0coYDXTF7zTezAP4xaWbuzcBwdUOQu41HsxvYRbUy1jNeO9lCeNXQWn2M tjTlKibzRHNQJd6Cao/JWhN4ZObdYFW1GqJCNl3ZnmN0PZptr0TlCABlstDH9Z3s 16vWs+lk0nyctM0yyYtkSiKaw8XMMkiZAgixkvP0s9MEUsEKz9fXM+cW9juv38Pf 1mRDLeQwF+KCDeF2cBzT5Q24YRypzLbEoqoZBMFhY0HnDdi1V7/B1vm3tprchz+Q eWcKdlJ8uM1LPMNDMOlM5W1tyI34ZAnVuo9etgOeUCFgSFa6I25Cj+ZiY0m5kyER 6mIELZixHzQHv33QC4e3zGU5vJPjNAwMic6wSB/aThy1hUxAQHp1Mu2qeBokigZN jC5xvwohEb0kLkK/izfvUz6mMH3kkSVjU4dbHP4Eni4OjAH23UnVVnqafQnpz3ni 4fJTfGNWPPQeAtVaov2Jg/ashwO0OeEh83kFmWoxedgLVOFkRRGcTiRHdfhFwzMh 7yivSHXY+G8= =v8DJ -END PGP SIGNATURE-
Re: mozilla - the forgotten package?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings, Am Mittwoch, 10. März 2004 22:39 schrieb Florian Weimer: Sven Hoexter wrote: Okay, if that's the case, I'm going to start a campaign for including Mozilla 1.4 (plus fixes) in stable. Well why just include 1.4 and not 1.6? AFAIK, 1.4 is the more stable branch, and fixes are still backported to it (at least by MandrakeSoft 8-). Is that your campaign? http://cert.uni-stuttgart.de/ticker/article.php?mid=1183 Imho security fixes for mozilla are very important. Some exploits currently existing in mozilla justifies some rc bugs for mozilla. Imho the consequences of being unable to provide sec. updates for a popular end-user client software is obvious: Kick the package out of stable, testing and unstable! Being in stable implicies security, which is NOT provided. Just me 2cents. Keep smiling yanosz -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iQIVAwUBQFBtVdAHMQ8GQaYRAQLQDA//R5txp+sE7Iu7kJjaoaD/WDK43kN6GXr5 m0+LlQD/BuS8aOnoqFqo7Zbj+p+S/cVI4fZ9ZoR5w1WSgKk0Dn875af/fLTIUMFQ DLpbI35KXwzSarSrya9P2tpBEXAQ2aLzhqnckureJ9s9uuxE0lcoYr6XnHBK90N2 0AcEzxeYMid04eqDGWK+TCEfDVm6g2XMnECEtJqxL3augt1tK7JXRNa9kOpkm3rZ lN8ostQXZ5s8Fe84TXfz4iSOFYBy5HfqM3tp1h7od/02Zw8p6bSTg/KiRZHwnp89 w8IT3hghbSEFeLfA2NpPpo6HIEwmnH5O67nO2NgQ0SOCrElBf8VKr2bWin6Q999A 3vAB1M0vNpeRTiYwGYzztdH7yo6A+jkcuPZL1DRIPT4dChOotS6zmW3v0TY2MVU5 xKtDK2G6xIS8k0tZ7MZ13tD2flGq6Vc/SVlcmfmv9EgIDJQLcukV7EnJsUbAq5/J jYTDOrWJ9K+leZ3obAswXLfNfJD6Hide/3CGrcf3WfARrlHaaRhWLBy1OrrrhL87 bYyJaONMEW+CQ3R39gBriuAjJ26o6ytssriErZkVnqUwWYovYV8/4I79jAd9vi4I YOpB8fBpq2LI2fH5JtFa4N15tfECcouIDfH4fG5jHvZ3zFDb1hJAKUKNQ3zbSk1j +yGIyCF6kq4= =XlV6 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mozilla - the forgotten package?
Greetings, Am Donnerstag, 11. März 2004 19:22 schrieb Phillip Hofmeister: On Thu, 11 Mar 2004 at 12:24:15PM -0500, Matt Zimmerman wrote: This introduces a whole new set of problems, given Mozilla's upgrade history (not preserving user configuration data, breaking compatibility with dependent applications, etc.) We could offer a second Mozilla package, leaving the current on in place for compatibility sakes. Good idea. Who is in charge with this decision? Keep smiling yanosz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mozilla - the forgotten package?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings, Am Mittwoch, 10. März 2004 22:39 schrieb Florian Weimer: Sven Hoexter wrote: Okay, if that's the case, I'm going to start a campaign for including Mozilla 1.4 (plus fixes) in stable. Well why just include 1.4 and not 1.6? AFAIK, 1.4 is the more stable branch, and fixes are still backported to it (at least by MandrakeSoft 8-). Is that your campaign? http://cert.uni-stuttgart.de/ticker/article.php?mid=1183 Imho security fixes for mozilla are very important. Some exploits currently existing in mozilla justifies some rc bugs for mozilla. Imho the consequences of being unable to provide sec. updates for a popular end-user client software is obvious: Kick the package out of stable, testing and unstable! Being in stable implicies security, which is NOT provided. Just me 2cents. Keep smiling yanosz -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iQIVAwUBQFBtVdAHMQ8GQaYRAQLQDA//R5txp+sE7Iu7kJjaoaD/WDK43kN6GXr5 m0+LlQD/BuS8aOnoqFqo7Zbj+p+S/cVI4fZ9ZoR5w1WSgKk0Dn875af/fLTIUMFQ DLpbI35KXwzSarSrya9P2tpBEXAQ2aLzhqnckureJ9s9uuxE0lcoYr6XnHBK90N2 0AcEzxeYMid04eqDGWK+TCEfDVm6g2XMnECEtJqxL3augt1tK7JXRNa9kOpkm3rZ lN8ostQXZ5s8Fe84TXfz4iSOFYBy5HfqM3tp1h7od/02Zw8p6bSTg/KiRZHwnp89 w8IT3hghbSEFeLfA2NpPpo6HIEwmnH5O67nO2NgQ0SOCrElBf8VKr2bWin6Q999A 3vAB1M0vNpeRTiYwGYzztdH7yo6A+jkcuPZL1DRIPT4dChOotS6zmW3v0TY2MVU5 xKtDK2G6xIS8k0tZ7MZ13tD2flGq6Vc/SVlcmfmv9EgIDJQLcukV7EnJsUbAq5/J jYTDOrWJ9K+leZ3obAswXLfNfJD6Hide/3CGrcf3WfARrlHaaRhWLBy1OrrrhL87 bYyJaONMEW+CQ3R39gBriuAjJ26o6ytssriErZkVnqUwWYovYV8/4I79jAd9vi4I YOpB8fBpq2LI2fH5JtFa4N15tfECcouIDfH4fG5jHvZ3zFDb1hJAKUKNQ3zbSk1j +yGIyCF6kq4= =XlV6 -END PGP SIGNATURE-
Re: mozilla - the forgotten package?
Greetings, Am Donnerstag, 11. März 2004 19:22 schrieb Phillip Hofmeister: On Thu, 11 Mar 2004 at 12:24:15PM -0500, Matt Zimmerman wrote: This introduces a whole new set of problems, given Mozilla's upgrade history (not preserving user configuration data, breaking compatibility with dependent applications, etc.) We could offer a second Mozilla package, leaving the current on in place for compatibility sakes. Good idea. Who is in charge with this decision? Keep smiling yanosz
Re: mozilla - the forgotten package?
Greetings, Am Mittwoch, 10. März 2004 17:06 schrieben Sie: Jan Lühr wrote: So is mozilla the forgotten package? Considering how popular mozilla is, making it secure would be worth the effort - imho. How many of Mozilla's security bugs which are fix during routine upgrades are discussed publicly? Can they be backported easily? I'm not in touch with the mozilla code. Thus I cannot say how easy it is to backport 'em. Keep smiling yanosz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mozilla - the forgotten package?
Greetings, Am Mittwoch, 10. März 2004 17:06 schrieben Sie: Jan Lühr wrote: So is mozilla the forgotten package? Considering how popular mozilla is, making it secure would be worth the effort - imho. How many of Mozilla's security bugs which are fix during routine upgrades are discussed publicly? Can they be backported easily? I'm not in touch with the mozilla code. Thus I cannot say how easy it is to backport 'em. Keep smiling yanosz
Re: mozilla - the forgotten package?
Greetings, Am Dienstag, 9. März 2004 17:20 schrieb Steve Kemp: On Tue, Mar 09, 2004 at 05:15:42PM +0100, Jan L??hr wrote: over the last months, various security related bugs in mozilla appeared and were fixed in new versions of mozilla - but what about the debian package? Are there any efforts for making mozilla secure or to backport the mozilla patches to debian? Due to depency with galeon new mozilla versions cannot be intergrated easily, but right now, the debian mozilla contains some seriuos security related bugs. So is mozilla the forgotten package? Considering how popular mozilla is, making it secure would be worth the effort - imho. I think it's a case of time and energy. I started updating the current woody packages to handle some of the reports, after mdz pointed me to a list. However it was very timeconsuming and very shortly after I started I stopped having to support graphical stable boxes; so it became a non issue for me. There are patches around for some (most?) of the holes, it just takes somebody with the patience to apply them and build fixed versions to share - then I'm sure we'd see a new stable release. So this is all in all a capacity problem? Doesn't have the debian security team enough ressource to port exisiting patches to debian packages? Why not enlarging the team? Keep smiling yanosz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mozilla - the forgotten package?
Greetings, Am Dienstag, 9. März 2004 20:54 schrieb Noah Meyerhans: On Tue, Mar 09, 2004 at 08:53:23PM +0100, Jan L?hr wrote: So this is all in all a capacity problem? Doesn't have the debian security team enough ressource to port exisiting patches to debian packages? Why not enlarging the team? You do not need to be a member of the security team to submit patches. Why don't you send some, and we'll release updated packages. sorry, I'm not a good c++ coder. I'll think about it, when I'm able to do so. Keep smiling yanosz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
mozilla - the forgotten package?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings, over the last months, various security related bugs in mozilla appeared and were fixed in new versions of mozilla - but what about the debian package? Are there any efforts for making mozilla secure or to backport the mozilla patches to debian? Due to depency with galeon new mozilla versions cannot be intergrated easily, but right now, the debian mozilla contains some seriuos security related bugs. So is mozilla the forgotten package? Considering how popular mozilla is, making it secure would be worth the effort - imho. Keep smiling yanosz -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iQIVAwUBQE3ttNAHMQ8GQaYRAQLUkw//QQYCWCLtPhe6l2bFllP8cDeSbfPu6dCn B1NpYneBP9lw5+feLfBMEzzKley2FXoSJTF6PMoEs8X5zSANPyMyRBvGRSyDq/Tf X7zUojiIsr8xgdnHYZCXfCcdPIKU2qnJvYvnvWZPai4TT+4TU0qDhbe26q5klqmX IC+YHuqUoeoaPHayKY2THurHS90Ex3qmB3LeZ7ngiAZWlEnscRNb+In/DSNXLdFg 9ViW67JOPYnGc5eHGrvVYZP/aIcJgsF6nEykHwf9Lef2dTs26aYZS2+5MV2NqB1z XdgtA+Jtl+ISTnjvYTn8Zx7tsk4Nu1TrJHsdtCyCbqv4WSJW9eO5T8w1wScMVNRt BBiQltSG4ZJNAlCb4uXZYxWCZ8mNH9BL8MmWJH4pCOoWOsjZV3Ve0e4IiLnbgyPH ay0gQ/6vsweCm+vrSu4QIuLysx/yDD84cEOThRyccI8dgxdJc8FERaRu422pfsAS /0HNh227kM3uqU/Ts/HlNG8jQWMrrr7nKjLA37pzXU9N13Vzu8gIwzyvQz3kMymm 25sxqkb4SifH61KAicjTOIXLQf4UBWlZHnaYTtCsc4BN7e3DmGwNy2Ozm5l7Fb76 Ji5+rVcLxf1UJedmlmruMc+XhvkdoCHuS057MGOb0hG6RpzZFB7/k9lvxFfLbM/B SnDUvkzxJFk= =e6ya -END PGP SIGNATURE-
Re: mozilla - the forgotten package?
Greetings, Am Dienstag, 9. März 2004 17:20 schrieb Steve Kemp: On Tue, Mar 09, 2004 at 05:15:42PM +0100, Jan L??hr wrote: over the last months, various security related bugs in mozilla appeared and were fixed in new versions of mozilla - but what about the debian package? Are there any efforts for making mozilla secure or to backport the mozilla patches to debian? Due to depency with galeon new mozilla versions cannot be intergrated easily, but right now, the debian mozilla contains some seriuos security related bugs. So is mozilla the forgotten package? Considering how popular mozilla is, making it secure would be worth the effort - imho. I think it's a case of time and energy. I started updating the current woody packages to handle some of the reports, after mdz pointed me to a list. However it was very timeconsuming and very shortly after I started I stopped having to support graphical stable boxes; so it became a non issue for me. There are patches around for some (most?) of the holes, it just takes somebody with the patience to apply them and build fixed versions to share - then I'm sure we'd see a new stable release. So this is all in all a capacity problem? Doesn't have the debian security team enough ressource to port exisiting patches to debian packages? Why not enlarging the team? Keep smiling yanosz
Re: mozilla - the forgotten package?
Greetings, Am Dienstag, 9. März 2004 20:54 schrieb Noah Meyerhans: On Tue, Mar 09, 2004 at 08:53:23PM +0100, Jan L?hr wrote: So this is all in all a capacity problem? Doesn't have the debian security team enough ressource to port exisiting patches to debian packages? Why not enlarging the team? You do not need to be a member of the security team to submit patches. Why don't you send some, and we'll release updated packages. sorry, I'm not a good c++ coder. I'll think about it, when I'm able to do so. Keep smiling yanosz
Re: Fwd: Re: [ox-en] Walther
Greetings, or is good code more important than this sort of stuff? What's the alternativ? Call the CIA or ths Spanish christian inquisition to check everybodies political correctness? Keep smiling yanosz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Re: [ox-en] Walther
Greetings, or is good code more important than this sort of stuff? What's the alternativ? Call the CIA or ths Spanish christian inquisition to check everybodies political correctness? Keep smiling yanosz
Tripwire (clone) which would you prefer?
Greetings, well, I looking for an open source intrusion detection. At first, tripwire caputures my attention, but the last open source version seems to be three years old - is it still in development or badly vulnerable? Then I searched for tripwire in the woody packages and found integrit and bsign - so which would you prefer and why? Are there any interesting other projekt that worth looking for? Keep smiling yanosz
Re: DSA 438 - bad server time, bad kernel version or information delayed?
Greetings, Am Sonntag, 22. Februar 2004 10:09 schrieb Jim Richardson: On Sat, 21 Feb 2004 22:20:05 +0100, Matt Zimmerman [EMAIL PROTECTED] wrote: On Sat, Feb 21, 2004 at 11:09:09AM +0100, Jan L?hr wrote: Am Samstag, 21. Februar 2004 01:10 schrieb Matt Zimmerman: .. CERT rarely has anything to do with coordinating disclosure, and there is no need to bring them into this discussion at all. The coordination that happens is between vendors, like Debian, as peers. Those last two cases are equivalent. Think about it. In the theory of capitalism, competition between vendors is the main aspect of going futher in development. Fortunately, Debian isn't driven by capitalism, and we benefit more from cooperation than competition. Debian competes for users, and just as importantly, developers, it's a free market of the mind :) And it's doing quite well. ;) My effords to switch a one machine to a current NetBSD or FreeBSD - just for testing purpose are not getting concrete ;) Keep smiling yanosz
Re: DSA 438 - bad server time, bad kernel version or information delayed?
Greetings, Am Samstag, 21. Februar 2004 01:10 schrieb Matt Zimmerman: .. CERT rarely has anything to do with coordinating disclosure, and there is no need to bring them into this discussion at all. The coordination that happens is between vendors, like Debian, as peers. Those last two cases are equivalent. Think about it. In the theory of capitalism, competition between vendors is the main aspect of going futher in development. As in every day capitalism, faster and cheaper is not always better - but if a product is well developed and reaches a high quality it might also be better - it's the balance that counts. Thus, won't be a little more competition between the vendors better for security at all? I know, that the flow of information between the vendors is really important and should not be stopped - but bigger effords in coding and testing should be hounored. Keep smiling yanosz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: output of last
Greetings,... Am Samstag, 21. Februar 2004 17:11 schrieb s. keeling: Incoming from Jan Lühr: Greetings, I discovered some strange output of the last command on our Woody Terminalserver (for X11). I have already posted it on debian-user-german, but I didn't get any answer. (I hope you don't mind, if I post it for the english speaking majority) Although I hope it is not security related, I thing, it may have a security related aspect, which I cannot ignore. At first a run ordinary chkrootkit scan (like I do it every one or two weeks). Two weeks? I run it every night. Well, perhaps I should increase the frequency. This time, it discovered: Checking `wted'... 24 deletion(s) between Thu Jan 1 01:00:00 1970 and Sun Apr 7 02:03:36 1974 Have you checked the chkrootkit archives for anything like this? Honestly, I had a simular problem with another machine, posted it in may 2002 and didn't get an answer till know. 17 deletion(s) between Sun Jan 25 08:20:56 2004 and Sun Apr 7 02:03:36 1974 Whaat?!? Between 2004 and 1974?!? That's my reaction, too. So I renamed all relatedi files in order to start with a non-corrupt database. But what could have caused this corruption? The machine itself is quite stable Sunspots? Maybe, but nothing else was wrong. Disk errors? Refering to smartmontools, none. Resource exhaustion? Maybe. This server use non-registered ram. (I know, I already fought my war against this machine, but the instiuttion I work is quite incooperativ) Unless you can definitively nail it down, I wouldn't start worrying until it happens again. Of course - but the server has to keep running. For the next days. I'll reinstall 'em from scratch if it is a sec issue but I hope it is not - maybe there was just a power interrution which left a corrupt databse behind. A really don't know. But because of being a valuable information on intruders, intruders or illegal root'ers might have compromised it. What's your opinion? Can you send logging to another (perhaps dedicated) machine? Good idea, I have thought of that but it seem to be rather paranoid for me. Maybe it is time to realize it. Keep smiling yanosz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
output of last
Greetings, I discovered some strange output of the last command on our Woody Terminalserver (for X11). I have already posted it on debian-user-german, but I didn't get any answer. (I hope you don't mind, if I post it for the english speaking majority) Although I hope it is not security related, I thing, it may have a security related aspect, which I cannot ignore. At first a run ordinary chkrootkit scan (like I do it every one or two weeks). This time, it discovered: Checking `wted'... 24 deletion(s) between Thu Jan 1 01:00:00 1970 and Sun Apr 7 02:03:36 1974 3 deletion(s) between Sun Apr 7 02:03:36 1974 and Tue Feb 3 09:08:53 2004 35 deletion(s) between Sun Jan 25 08:20:56 2004 and Wed Feb 4 09:38:39 2004 13 deletion(s) between Sun Jan 25 08:20:56 2004 and Wed Feb 4 23:41:11 2004 101 deletion(s) between Thu Feb 5 00:02:52 2004 and Wed Mar 25 18:24:58 1970 1 deletion(s) between Wed Mar 25 18:24:58 1970 and Wed Mar 25 18:24:58 1970 8 deletion(s) between Sun Apr 7 02:03:36 1974 and Mon Feb 9 09:01:04 2004 8 deletion(s) between Sun Jan 25 08:20:56 2004 and Tue Feb 10 10:56:08 2004 8 deletion(s) between Tue Feb 10 10:57:03 2004 and Tue Feb 10 12:09:25 2004 1 deletion(s) between Sun Jan 25 08:20:56 2004 and Tue Feb 10 13:40:32 2004 17 deletion(s) between Sun Jan 25 08:20:56 2004 and Sun Apr 7 02:03:36 1974 31 deletion(s) between Sun Jan 25 08:20:56 2004 and Fri Feb 13 09:32:27 2004 2 deletion(s) between Sun Jan 25 08:20:56 2004 and Fri Feb 13 11:51:10 2004 2 deletion(s) between Fri Feb 13 11:51:41 2004 and Sat Feb 14 21:11:51 2004 14 deletion(s) between Sun Feb 15 10:19:39 2004 and Sun Apr 7 02:03:36 1974 47 deletion(s) between Sun Jan 25 08:20:56 2004 and Wed Feb 18 14:27:08 2004 19 deletion(s) between Thu Feb 19 00:19:47 2004 and Fri Feb 20 09:28:55 2004 20 deletion(s) between Sun Jan 25 08:20:56 2004 and Fri Feb 20 14:09:22 2004 sadly (or luckily ;) no other routing found anything else. This output is quite strage. While nearly all entries are releated to 2004 others went back to 1974 or even 1970. So I suspected a corrupt database and the output of last seem to endorse my suspecion. root pts/2192.168.1.253Fri Feb 20 14:13 still logged in root pts/1192.168.1.253Fri Feb 20 14:10 still logged in root pts/1192.168.1.253Fri Feb 20 14:09 - 14:09 (00:00) Ok, that's correct rucker:0 [EMAIL PROTECTED]@** mfelten Thu Jan 1 01:00 still logged in rucker is neither a computer nor a user and mfelten is a user. Futhermore the machine doesn't have an uptime of two months - kernel updates forced the machine to be rebooted. cal:0[EMAIL PROTECTED]@**Thu Jan 1 01:00 - 01:00 (00:00) cal:0[EMAIL PROTECTED]@**Thu Jan 1 01:00 - 01:00 (00:00) cal:0[EMAIL PROTECTED]@**Thu Jan 1 01:00 - 01:00 (00:00) cal:0[EMAIL PROTECTED]@**Thu Jan 1 01:00 - 01:00 (00:00) cal:0[EMAIL PROTECTED]@**Thu Jan 1 01:00 - 01:00 (00:00) cal:0[EMAIL PROTECTED]@**Thu Jan 1 01:00 - 01:00 (00:00) cal:0[EMAIL PROTECTED]@**Thu Jan 1 01:00 - 01:00 (00:00) cal:0**Thu Jan 1 01:00gone - no logout These are quite strange entries and there is neither user or machine called cal. h*** h*** rucker:0 Thu Jan 1 01:00gone - no logout rucker again?! root pts/1192.168.1.253Thu Feb 19 00:03 - 00:19 (00:16) root pts/1192.168.1.253Wed Feb 18 23:47 - 23:48 (00:00) root pts/1alphaWed Feb 18 14:54 - 14:54 (00:00) root pts/1alphaWed Feb 18 14:27 - 14:45 (00:18) That's ok. h*** ***h**@ h***h*** Thu Jan 1 01:00gone - no logout nt-55.lo [EMAIL PROTECTED]@**Thu Jan 1 01:00 - 01:00 (00:00) cal:0[EMAIL PROTECTED]@**Thu Jan 1 01:00 - 01:00 (00:00) cal:0[EMAIL PROTECTED]@**Thu Jan 1 01:00 - 01:00 (00:00) cal:0[EMAIL PROTECTED]@**Thu Jan 1 01:00 - 01:00 (00:00) cal:0[EMAIL PROTECTED]@**Thu Jan 1 01:00 - 01:00 (00:00) cal:0[EMAIL PROTECTED]@**Thu Jan 1 01:00 - 01:00 (00:00) cal:0[EMAIL PROTECTED]@**Thu Jan 1 01:00 - 01:00 (00:00) cal:0[EMAIL PROTECTED]@**Thu Jan 1 01:00 - 01:00 (00:00) cal:0[EMAIL PROTECTED]@**Thu Jan 1 01:00 - 01:00 (00:00) cal:0**Thu Jan 1 01:00 - 01:00 (00:00) That's not. Let's go one. root pts/1client-64.local Tue Feb 17 10:29 - 10:29 (00:00) fatmay client-50.lo Tue Feb 17 09:00 - 10:47 (01:46) swojmon client-51.lo Tue Feb 17 08:59 - 10:47 (01:47) h*** h*** h***h*** Thu Jan 1
Re: DSA 438 - bad server time, bad kernel version or information delayed?
Greetings, Am Samstag, 21. Februar 2004 01:10 schrieb Matt Zimmerman: .. CERT rarely has anything to do with coordinating disclosure, and there is no need to bring them into this discussion at all. The coordination that happens is between vendors, like Debian, as peers. Those last two cases are equivalent. Think about it. In the theory of capitalism, competition between vendors is the main aspect of going futher in development. As in every day capitalism, faster and cheaper is not always better - but if a product is well developed and reaches a high quality it might also be better - it's the balance that counts. Thus, won't be a little more competition between the vendors better for security at all? I know, that the flow of information between the vendors is really important and should not be stopped - but bigger effords in coding and testing should be hounored. Keep smiling yanosz
Re: output of last
Greetings,... Am Samstag, 21. Februar 2004 17:11 schrieb s. keeling: Incoming from Jan Lühr: Greetings, I discovered some strange output of the last command on our Woody Terminalserver (for X11). I have already posted it on debian-user-german, but I didn't get any answer. (I hope you don't mind, if I post it for the english speaking majority) Although I hope it is not security related, I thing, it may have a security related aspect, which I cannot ignore. At first a run ordinary chkrootkit scan (like I do it every one or two weeks). Two weeks? I run it every night. Well, perhaps I should increase the frequency. This time, it discovered: Checking `wted'... 24 deletion(s) between Thu Jan 1 01:00:00 1970 and Sun Apr 7 02:03:36 1974 Have you checked the chkrootkit archives for anything like this? Honestly, I had a simular problem with another machine, posted it in may 2002 and didn't get an answer till know. 17 deletion(s) between Sun Jan 25 08:20:56 2004 and Sun Apr 7 02:03:36 1974 Whaat?!? Between 2004 and 1974?!? That's my reaction, too. So I renamed all relatedi files in order to start with a non-corrupt database. But what could have caused this corruption? The machine itself is quite stable Sunspots? Maybe, but nothing else was wrong. Disk errors? Refering to smartmontools, none. Resource exhaustion? Maybe. This server use non-registered ram. (I know, I already fought my war against this machine, but the instiuttion I work is quite incooperativ) Unless you can definitively nail it down, I wouldn't start worrying until it happens again. Of course - but the server has to keep running. For the next days. I'll reinstall 'em from scratch if it is a sec issue but I hope it is not - maybe there was just a power interrution which left a corrupt databse behind. A really don't know. But because of being a valuable information on intruders, intruders or illegal root'ers might have compromised it. What's your opinion? Can you send logging to another (perhaps dedicated) machine? Good idea, I have thought of that but it seem to be rather paranoid for me. Maybe it is time to realize it. Keep smiling yanosz
Re: DSA 438 - bad server time, bad kernel version or information delayed?
Greetings,. Am Donnerstag, 19. Februar 2004 00:37 schrieb Michael Stone: On Wed, Feb 18, 2004 at 11:37:19PM +0100, Jan Lühr wrote: But if knowlegde about this vuln is availeable - if fixes are done, but not avaible yet, how do I protect myself? Are you less secure today than yesterday? No. Someone will always know about a vulnerability before you do, you need to deal with that. You protect yourself by disabling unnecessary services, teaching your users good security habits, elminating replayable passwords, keeping good logs, reviewing those logs, making good backups, etc. Can you still be compromised? Yup. Are there people out there right now exploiting vulnerabilities you don't know about? Yup. All you can do is established a layered security plan and prepare a disaster recovery plan for the inevitable. Of cours - these are the main aspects of a secure installation, but as we have seen in the recent debian compromise it may not be enough. Imho opinion, please correct me if I'm wrong - an exploit, known for many weeks by much people, trying to correct it, is more threadening than some exoctic exploit, which may be known to a bunch of people. Thus the information about the discussed exploit can be easily obtained by some bad guy. What about establishing some kind of warning service? E.g. sshd has a well known serious leak, you should shut it down for the next few days. Keep smiling yanosz P.S. May apologies for my last e-mails - I'm trying not to go on trolling, maybe I was to astonished and to excited. The DST has done quite a good job for the recent months / yers. Go on! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA 438 - bad server time, bad kernel version or information delayed?
Greetings,. Am Donnerstag, 19. Februar 2004 14:22 schrieben Sie: Jan Lühr wrote: Well, of course you might have quite good reasons for doing so, but for me, this is quite a good reason for changing the distri or os. But to what? Currently, you have two choices: delayed, limited disclosure and no disclosure at all. Please don't take may yesterdays escapades serious, as I posted, I was quite stupid in a rude and I apologies for that. No vendor currently offers what once was called full disclosure, even in a delayed fashion. Hiding unfixed holes is one thing (and I appreciate that partly) but hiding already fixed packages is quite astonishing and you cannot tell me you need more than two weeks to test a simple correction. There's an implicit contract among GNU/Linux distributors: you wait with disclosure until most parties are ready. Red Hat rushed ahead several times and the company still has early access to information. Debian would risk to get expelled from the vendor-sec community if it did the same, on a more regular scale, I suppose. This is exactly the same policy M$ have - but the point is, you could at least inform your users. Nobody does this, and it could upset users unnecessarily. There are many pitfalls to avoid in this area. Theo de Raadt's notorious disclosure of that OpenSSH bug should serve as a warning to others. I agree. Keep smiling yanosz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA 438 - bad server time, bad kernel version or information delayed?
Greetings, Am Donnerstag, 19. Februar 2004 14:24 schrieben Sie: Jan Lühr wrote: But if knowlegde about this vuln is availeable - if fixes are done, but not avaible yet, how do I protect myself? You don't. Tough luck, of course, but that's the price for running affordable, off-the-shelf software (free or proprietary). well, this might be a reason for using computers in situations we use 'em today. I'm just feeling like a helpless person, threadening by a serious disease, who is going to be informened about it, when a cure exists. Trust me, that doesn't feel right. (Hope to) Keep smiling yanosz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA 438 - bad server time, bad kernel version or information delayed?
Greetings, Am Donnerstag, 19. Februar 2004 14:28 schrieben Sie: Jan Lühr wrote: But the dominance of the CERT is excactly the point I'm criticising. CERT/CC is no longer dominant. Many people now disclose their findings to other coordinators and get paid for that service. Those who don't believe in money don't support CERT/CC either because CERT/CC is selling the information they collect via the Internet Security Alliance. That looks quite chaotic. Are there (in you opinion) better ways to do so? Keep smiling yanosz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA 438 - bad server time, bad kernel version or information delayed?
Greetings,. Am Donnerstag, 19. Februar 2004 05:05 schrieb Bernd S. Brentrup: On Wed, Feb 18, 2004 at 04:44:15PM -0500, Michael Stone wrote: On Wed, Feb 18, 2004 at 09:17:13PM +0100, Florian Weimer wrote: Yes, this is the norm. Debian hides security bugs from its users for extended periods of time. begone, troll Casting a spell on him won't work either :-), he'll raise his head again next time this issue comes up. Obviously he isn't capable of accepting defeat. Sorry for trolling. I have been astonished and excited. I hope you forgive me. Keep smiling yanosz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA 438 - bad server time, bad kernel version or information delayed?
Greetings,. Am Donnerstag, 19. Februar 2004 00:37 schrieb Michael Stone: On Wed, Feb 18, 2004 at 11:37:19PM +0100, Jan Lühr wrote: But if knowlegde about this vuln is availeable - if fixes are done, but not avaible yet, how do I protect myself? Are you less secure today than yesterday? No. Someone will always know about a vulnerability before you do, you need to deal with that. You protect yourself by disabling unnecessary services, teaching your users good security habits, elminating replayable passwords, keeping good logs, reviewing those logs, making good backups, etc. Can you still be compromised? Yup. Are there people out there right now exploiting vulnerabilities you don't know about? Yup. All you can do is established a layered security plan and prepare a disaster recovery plan for the inevitable. Of cours - these are the main aspects of a secure installation, but as we have seen in the recent debian compromise it may not be enough. Imho opinion, please correct me if I'm wrong - an exploit, known for many weeks by much people, trying to correct it, is more threadening than some exoctic exploit, which may be known to a bunch of people. Thus the information about the discussed exploit can be easily obtained by some bad guy. What about establishing some kind of warning service? E.g. sshd has a well known serious leak, you should shut it down for the next few days. Keep smiling yanosz P.S. May apologies for my last e-mails - I'm trying not to go on trolling, maybe I was to astonished and to excited. The DST has done quite a good job for the recent months / yers. Go on!
Re: DSA 438 - bad server time, bad kernel version or information delayed?
Greetings, Am Donnerstag, 19. Februar 2004 09:39 schrieb Jean Christophe ANDRÉ: Le jeudi 19 février 2004 à 09h24 (+0100), Jan Lühr écrivait : What about establishing some kind of warning service? E.g. sshd has a well known serious leak, you should shut it down for the next few days. Warning: the Linux kernel has a well known serious leak, you should shut all your servers down for the next few weeks. Sorry, I couln't resist! ;-))) ;) I understand - but I rather thought of: mremap bug, wacht out for theses kind of processes (wich have to run for quite a long time), This is not an easy decision: the alert may alert bad guys too... Oh! There is some kind vulnerability nobody knows and has corrected in SSH! Let's look for it and use it quick before anybody has been able to patch it! Well yeah, but Imho - correct me if I'm wrong, these kind of bad guys, hanging all night long in IRC have sources, apart from the official announcements. All I'm asking for is getting to know the things they know - not critical data use to create exploit, just general information, what is currently threadening the security of my system and how I can detect it. But this was not the main point of my first mail: I only ask for putting some information about the delay in the announcement. It will just be usefull (and alertless) for these people (like me) checking for the kernel compile time against the announcement date. I agree. Keep smiling yanosz
Re: DSA 438 - bad server time, bad kernel version or information delayed?
Greetings,. Am Donnerstag, 19. Februar 2004 14:22 schrieben Sie: Jan Lühr wrote: Well, of course you might have quite good reasons for doing so, but for me, this is quite a good reason for changing the distri or os. But to what? Currently, you have two choices: delayed, limited disclosure and no disclosure at all. Please don't take may yesterdays escapades serious, as I posted, I was quite stupid in a rude and I apologies for that. No vendor currently offers what once was called full disclosure, even in a delayed fashion. Hiding unfixed holes is one thing (and I appreciate that partly) but hiding already fixed packages is quite astonishing and you cannot tell me you need more than two weeks to test a simple correction. There's an implicit contract among GNU/Linux distributors: you wait with disclosure until most parties are ready. Red Hat rushed ahead several times and the company still has early access to information. Debian would risk to get expelled from the vendor-sec community if it did the same, on a more regular scale, I suppose. This is exactly the same policy M$ have - but the point is, you could at least inform your users. Nobody does this, and it could upset users unnecessarily. There are many pitfalls to avoid in this area. Theo de Raadt's notorious disclosure of that OpenSSH bug should serve as a warning to others. I agree. Keep smiling yanosz
Re: DSA 438 - bad server time, bad kernel version or information delayed?
Greetings, Am Donnerstag, 19. Februar 2004 14:24 schrieben Sie: Jan Lühr wrote: But if knowlegde about this vuln is availeable - if fixes are done, but not avaible yet, how do I protect myself? You don't. Tough luck, of course, but that's the price for running affordable, off-the-shelf software (free or proprietary). well, this might be a reason for using computers in situations we use 'em today. I'm just feeling like a helpless person, threadening by a serious disease, who is going to be informened about it, when a cure exists. Trust me, that doesn't feel right. (Hope to) Keep smiling yanosz
Re: DSA 438 - bad server time, bad kernel version or information delayed?
Greetings, Am Donnerstag, 19. Februar 2004 14:28 schrieben Sie: Jan Lühr wrote: But the dominance of the CERT is excactly the point I'm criticising. CERT/CC is no longer dominant. Many people now disclose their findings to other coordinators and get paid for that service. Those who don't believe in money don't support CERT/CC either because CERT/CC is selling the information they collect via the Internet Security Alliance. That looks quite chaotic. Are there (in you opinion) better ways to do so? Keep smiling yanosz
Re: DSA 438 - bad server time, bad kernel version or information delayed?
Greetings,. Am Donnerstag, 19. Februar 2004 05:05 schrieb Bernd S. Brentrup: On Wed, Feb 18, 2004 at 04:44:15PM -0500, Michael Stone wrote: On Wed, Feb 18, 2004 at 09:17:13PM +0100, Florian Weimer wrote: Yes, this is the norm. Debian hides security bugs from its users for extended periods of time. begone, troll Casting a spell on him won't work either :-), he'll raise his head again next time this issue comes up. Obviously he isn't capable of accepting defeat. Sorry for trolling. I have been astonished and excited. I hope you forgive me. Keep smiling yanosz
Re: DSA 438 - bad server time, bad kernel version or information delayed?
Greeting,. Am Donnerstag, 19. Februar 2004 15:12 schrieb Florian Weimer: Jan Lühr wrote: You don't. Tough luck, of course, but that's the price for running affordable, off-the-shelf software (free or proprietary). well, this might be a reason for using computers in situations we use 'em today. Probably yes. If the costs for software production were one or two magnitudes higher because only error rates in the range of one error per 10 KSLOCS were tolerated by the market, it's unlikely that anybody would use free software for its technical merits. 8-) I'm just feeling like a helpless person, threadening by a serious disease, who is going to be informened about it, when a cure exists. Trust me, that doesn't feel right. Large institutions tend to react quite irrational if they are confronted with possibly far-reaching defects. It doesn't matter if a fix is available, it's often very expensive to deploy. The security announcement alone can cause significant costs and service disruption. Well. what about providing binary only package if they are ready. No debug symbols, no changelog. Just put a tested fix on the Server, do a quick post like local root exploit fixed, CVE id is ... and nothing more. Thus debian users are able to protect themself and the blackhats would have to scan the whole binary in order to speculate for the course. When the other's have done theirs - release the detailed information. This might be affordable. Keep smiling yanosz
Re: DSA 438 - bad server time, bad kernel version or information delayed?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings, Am Mittwoch, 18. Februar 2004 19:06 schrieb Steve Kemp: On Wed, Feb 18, 2004 at 11:59:06PM +0700, Jean Christophe ANDR? wrote: Does any body could tell me why the /boot/vmlinuz-2.4.18-1-686 from kernel-image-2.4.18-1-686 version 2.4.18-12.2 is dated Feb 1 19:53 instead of today??? The obvious reason is that the kernel was built then, but the DSA wasn't released until now. (Maybe for coordination with other vendors, maybe to wait for all the other kernels to be built so there could be a release of them all at the same time). Does this mean, that a well known exploit was kept back for nearly three weeks, just because some odd vendors were unable to build there kernels in time? After the last OpenSSH exploit, I thought that this kind of intransparency is limited to OpenBSD, but to what f*** h*** is OpenSource software driving to? Tranparency is the most important aspect of secure OpenSource Software. (Anyway, imho it's the one and only argument for OpenSource software beeing morre secure then other.) What's going on here? Keep smiling yanosz P.S. Please forgive the 4-letter words, but I'm quit excited - I beg your pardon. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iQIVAwUBQDO0/NAHMQ8GQaYRAQKXNQ//Y/tIRHPHAwYRJomB1B8hyO4cpVQymizn 0VHSMZzD7CfMwo5MF8hR0K9DlQvnLvUSYxC68Ke/BtIhG+Qic7GbLefuv1pCxnrh p98QsjK//u/M5yw1mRVEiC6zwmCd5yLjqAOt19VBfAHKDiX5ODP4lG3CwPjG8OMR 6kTm593nw26KjJLMFCwkIYrb4Cu+DnMJ88fzKS9DYx1QH4HKkWjZs0uw8KLHo6qh v5osKWZZm5HJeucp5mCUtsuCEEWr8r3F2M6dlW6KOnxG39hnRhv95hjMaSbgzfJJ yv/Z+bRLLuCaP9eTLQNZcm/oncvU0riCBn4Sm0+XkxooFvdZB7d63p3itwhLJyjl A+p5NIflml041QlpS9FZyGetc7djecDQp+nJzUrb2WTQU+XBSV8eWrAvVOeuIwgO lbG7pVC/J7m+ksQE2ouq7zDqUgL5z4LxLNbu0ARqbzvxnfm8d7Qo+7JGWrkwPEtn QprqOuDadrN3WoI4TzPyKIJ0rAQRQAWojorwh3srF3AuSxtt41LV5cS08BunNLOH NYqlu+T49ghoIdM00tnTB9vd9LkIPaFFi0/swFO8NdlYt1hew0SNjVAlBUcgtp7z vu41qNFtacn1YMgrnJGV3UCr30U4KjbMzlTWPRTOZXKoLEwk0R3TLwWT+Y5jjd43 wXKAXm+uqxw= =zZqZ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA 438 - bad server time, bad kernel version or information delayed?
Greetings, Am Mittwoch, 18. Februar 2004 21:31 schrieb Otavio Salvador: Florian Weimer [EMAIL PROTECTED] writes: Jan Lühr wrote: Does this mean, that a well known exploit was kept back for nearly three weeks, just because some odd vendors were unable to build there kernels in time? Yes, this is the norm. Debian hides security bugs from its users for extended periods of time. Yes but this have a reason. Before upload a fix this need be available in all supported archs and tested since major or users install it trusting Debian Security Team and 'cause of this, should not fail ;-) Well, of course you might have quite good reasons for doing so, but for me, this is quite a good reason for changing the distri or os. Hiding unfixed holes is one thing (and I appreciate that partly) but hiding already fixed packages is quite astonishing and you cannot tell me you need more than two weeks to test a simple correction. May I ask you what local / remote root exploit-fixes are you holding back currently? Should I switch of my sshd for the next few days or does the current bash have an unfixed local root exploit? This is exactly the same policy M$ have - but the point is, you could at least inform your users. An unknown local root exploit was one of the key parts in the debian server compromise and we have all seen the consequences. Surely, you can see, that I want to keep this risk as small as possible on my servers. Keep smiling yanosz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA 438 - bad server time, bad kernel version or information delayed?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings, Does this mean, that a well known exploit was kept back for nearly three weeks, just because some odd vendors were unable to build there kernels in time? Yes, this is the norm. Debian hides security bugs from its users for extended periods of time. Yes but this have a reason. Before upload a fix this need be available in all supported archs and tested since major or users install it trusting Debian Security Team and 'cause of this, should not fail ;-) Well, of course you might have quite good reasons for doing so, but for me, this is quite a good reason for changing the distri or os. Hiding unfixed holes is one thing (and I appreciate that partly) but hiding already fixed packages is quite astonishing and you cannot tell me you need more than two weeks to test a simple correction. Take it easy. I take security threads serious. Think of beeing avoidable vulnerable for nearly three weeks is a pain in my stomach. Maybe you are right, you should switch to another O/S. I bet you they coordinate and delay disclosure as well. Or better yet, you can switch to MS, which you are lucky if you get a patch in 2 weeks time. M$, you are kidding ;) Look at it this way: Debian Security Team (DST) finds out about a security bug from an organization (let's say CERT for the sake of discussion). CERT asks Debian to prepare for release but delay disclosure until further notice so all the CERT Coordinated Vendors (I believe Debian is one) can get on board. Debian decides to go against CERT and release immediately after the fix is made. CERT then decides they will no longer tell DST in advance since they breached trust. DST then finds out about the vulnerability the same time the rest of the world does. DST then rushes about (after the announcement) to put together a package and release a DSA. By now they are several hours or a day behind everyone else. Would you still prefer DST ignore coordinated release schedules? If so...perhaps you are correct...you could switch to a different O/S or Distro. Let's see: RedHatGoing Commercial..hope you have a deep pocket book. (BTW, they obey coordinated releases also). FedoraStill in it's infancy and organizing from the RedHat break off. Mandrake...They have Coordinated releases too. Any other distrodo they have security releases? But the dominance of the CERT is excactly the point I'm criticising. Even it is necessary to coordinate the sec affords - imho fixies should be applied if they are ready and not if some organisation say so. Anyhow, please sit back, take a few deep breaths and stop throwing such a stink. ok. May I ask you what local / remote root exploit-fixes are you holding back currently? Should I switch of my sshd for the next few days or does the current bash have an unfixed local root exploit? Not worth answering Please don't take it serious - it was meant to be ironic. I beg you pardon, if you are insulted by that. This is exactly the same policy M$ have - but the point is, you could at least inform your users. Yes, inform the users, let the ENTIRE hack community know, don't provide a fix. Then the release coordinator (CERT) gets mad at you...see above. How is this any better? This is not what I'm talking about - unfixed vuln. must be held back. An unknown local root exploit was one of the key parts in the debian server compromise and we have all seen the consequences. Yes, it was. There are probably several hundred unknown local root exploits. The source code is open, why not put your words into action and start finding some flaws? I neither have the knowlegde nor the time for doing that. But the point at is, that these vuln. are not avoidable at the moment - the last has been avoidable for nearly three weeks. Surely, you can see, that I want to keep this risk as small as possible on my servers. I do also. well, it seems, that we agreed at last ;) Keep smiling yanosz -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iQIVAwUBQDPmqNAHMQ8GQaYRAQJRPA//QsTfQrTC4AS6TGwZMQz6mo2t+0TI5Ulq 93bquRnk+mXSYTgOoOC925YJ5O5Vj/9qUMqk8aQq0LQx5g+qOM31vTKRCUBY8XIp aWuVXiL1iMvncwJGURzyweew0QHb1RYsl7zr9RMZS2M1QwxdfnI2INcevwaBUG3n QDUnxWAokSxkNMRDlojaFEzzlW3iFauVrzPqr1AfO0+xv78mi6YGxBVvLIWbx/0S lw0yc2Pm0Cd3YzSFx5tqKortMeTYt1rkiCyPPlq/uCSLoIygtHrII4N/IuBPKFMW I3xAuNs2cHM92V33Oac4juUs7j35jaQecEZPNKQZ0QPp4pgcSSQ2Mda56/bNC0sl SzjLJPiVN6akLx4naxssmF2Rw61J/Z9PiEXnwX2/kc6gCs2y4+s5SFY8FKnyIjVe 7tBdilImLMt63CgdRRb332Ji3MNXjmdx8lbyJep0wHvvixslAwhfKjkv0bV/6+lB r+7c2bQ5uOvWS+TXZg9GCVeuBH2l8tRcWnuN7OWfV7H5XdAWGZ6ewVxgg6Vf2FFC bgqJ79PMDHFj8/zBmihedefKXu06qGQs/4tCBqQH3xKmgsArmSvsfxLx4CFfB5/X J6Bt66N2S58ZMkrRp+wiQqkFrI24euAPcHxQLloi2zSYuItilMF3/Stqkedgr/09 BSms9+Cean8= =Sp85 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe.
Re: DSA 438 - bad server time, bad kernel version or information delayed?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings, Am Mittwoch, 18. Februar 2004 22:47 schrieb Michael Stone: On Wed, Feb 18, 2004 at 10:36:35PM +0100, Jan Lühr wrote: Well, of course you might have quite good reasons for doing so, but for me, this is quite a good reason for changing the distri or os. Goodbye. Hiding unfixed holes is one thing (and I appreciate that partly) but hiding already fixed packages is quite astonishing and you cannot tell me you need more than two weeks to test a simple correction. I don't think anyone in a position to tell you such a thing did so. If you want to amuse yourself by wild unfounded speculation that's your prerogative, but I have to say that approach is likely to find you pissing in the wrong stream. Ok, I thing your are right here. But if knowlegde about this vuln is availeable - if fixes are done, but not avaible yet, how do I protect myself? Keep smiling yanosz -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iQIVAwUBQDPpJdAHMQ8GQaYRAQKAZQ//c4YYJ0x5a1k7sN2xj+S8uAoe2tYOFkW4 uUHdEChXnDWHfvs/JiNWItWLUuFcKVSHcYH5v3g3nkGusDLZesrnXH1e6KL7Qu3B kKElVfpmDhWRVZ8zdUJhKRUa9kwdZZKAMlXC/bYiPqyaIOZCHg0VwXZurcCOanOR epuJSomXVvL+wL2SIAkg/AbZvhtTEf5cHqoYjnuf4QnGUyPkFEHNz9UuU8XLv7ot zQjDWCP6b7M4y4XClwOFjeTcGEqUuF/mg9QzDuyw6lZgI9it3XMW6g786uGGY9TT Ss3DzPNxikuZBxBesH7Q2Ue+UQm9Ym87OQZ6+YYsW/XCIDIE8tyC/N8+elMTr7kh kYntDX/D0UHwPNagiWdLWoOoibl07EU35z6S891np0Hku0nOhQDP/g6e5vgeqrMN 7VRjEmig/wHCRALh1OiBJGv4FfofZZt8wjr9xZZ66W1/vbpi4LaBv/+MTQoGf1p7 thVY9MSKDbCjKVwMiWRYN5AogoFXR/Gr6Xx1cWzWaveGaIxyAGFNVZ71HLarX0qt jT4U5cy9Qo0NdtgTHPy9BOWRH4DOyeZMaD+bqdmr1P8OoaZGue/RXq+fzNvgdG29 kpvg0jRVQBpVJQT4JCt2vHOb49twplCC2U4k+E9e50gmD2sqP3qpnHH0P5irmEqP mgEUYQM7l9c= =nFoY -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA 438 - bad server time, bad kernel version or information delayed?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings, Am Mittwoch, 18. Februar 2004 19:06 schrieb Steve Kemp: On Wed, Feb 18, 2004 at 11:59:06PM +0700, Jean Christophe ANDR? wrote: Does any body could tell me why the /boot/vmlinuz-2.4.18-1-686 from kernel-image-2.4.18-1-686 version 2.4.18-12.2 is dated Feb 1 19:53 instead of today??? The obvious reason is that the kernel was built then, but the DSA wasn't released until now. (Maybe for coordination with other vendors, maybe to wait for all the other kernels to be built so there could be a release of them all at the same time). Does this mean, that a well known exploit was kept back for nearly three weeks, just because some odd vendors were unable to build there kernels in time? After the last OpenSSH exploit, I thought that this kind of intransparency is limited to OpenBSD, but to what f*** h*** is OpenSource software driving to? Tranparency is the most important aspect of secure OpenSource Software. (Anyway, imho it's the one and only argument for OpenSource software beeing morre secure then other.) What's going on here? Keep smiling yanosz P.S. Please forgive the 4-letter words, but I'm quit excited - I beg your pardon. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iQIVAwUBQDO0/NAHMQ8GQaYRAQKXNQ//Y/tIRHPHAwYRJomB1B8hyO4cpVQymizn 0VHSMZzD7CfMwo5MF8hR0K9DlQvnLvUSYxC68Ke/BtIhG+Qic7GbLefuv1pCxnrh p98QsjK//u/M5yw1mRVEiC6zwmCd5yLjqAOt19VBfAHKDiX5ODP4lG3CwPjG8OMR 6kTm593nw26KjJLMFCwkIYrb4Cu+DnMJ88fzKS9DYx1QH4HKkWjZs0uw8KLHo6qh v5osKWZZm5HJeucp5mCUtsuCEEWr8r3F2M6dlW6KOnxG39hnRhv95hjMaSbgzfJJ yv/Z+bRLLuCaP9eTLQNZcm/oncvU0riCBn4Sm0+XkxooFvdZB7d63p3itwhLJyjl A+p5NIflml041QlpS9FZyGetc7djecDQp+nJzUrb2WTQU+XBSV8eWrAvVOeuIwgO lbG7pVC/J7m+ksQE2ouq7zDqUgL5z4LxLNbu0ARqbzvxnfm8d7Qo+7JGWrkwPEtn QprqOuDadrN3WoI4TzPyKIJ0rAQRQAWojorwh3srF3AuSxtt41LV5cS08BunNLOH NYqlu+T49ghoIdM00tnTB9vd9LkIPaFFi0/swFO8NdlYt1hew0SNjVAlBUcgtp7z vu41qNFtacn1YMgrnJGV3UCr30U4KjbMzlTWPRTOZXKoLEwk0R3TLwWT+Y5jjd43 wXKAXm+uqxw= =zZqZ -END PGP SIGNATURE-
Re: DSA 438 - bad server time, bad kernel version or information delayed?
Greetings, Am Mittwoch, 18. Februar 2004 21:31 schrieb Otavio Salvador: Florian Weimer [EMAIL PROTECTED] writes: Jan Lühr wrote: Does this mean, that a well known exploit was kept back for nearly three weeks, just because some odd vendors were unable to build there kernels in time? Yes, this is the norm. Debian hides security bugs from its users for extended periods of time. Yes but this have a reason. Before upload a fix this need be available in all supported archs and tested since major or users install it trusting Debian Security Team and 'cause of this, should not fail ;-) Well, of course you might have quite good reasons for doing so, but for me, this is quite a good reason for changing the distri or os. Hiding unfixed holes is one thing (and I appreciate that partly) but hiding already fixed packages is quite astonishing and you cannot tell me you need more than two weeks to test a simple correction. May I ask you what local / remote root exploit-fixes are you holding back currently? Should I switch of my sshd for the next few days or does the current bash have an unfixed local root exploit? This is exactly the same policy M$ have - but the point is, you could at least inform your users. An unknown local root exploit was one of the key parts in the debian server compromise and we have all seen the consequences. Surely, you can see, that I want to keep this risk as small as possible on my servers. Keep smiling yanosz
Re: DSA 438 - bad server time, bad kernel version or information delayed?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings, Does this mean, that a well known exploit was kept back for nearly three weeks, just because some odd vendors were unable to build there kernels in time? Yes, this is the norm. Debian hides security bugs from its users for extended periods of time. Yes but this have a reason. Before upload a fix this need be available in all supported archs and tested since major or users install it trusting Debian Security Team and 'cause of this, should not fail ;-) Well, of course you might have quite good reasons for doing so, but for me, this is quite a good reason for changing the distri or os. Hiding unfixed holes is one thing (and I appreciate that partly) but hiding already fixed packages is quite astonishing and you cannot tell me you need more than two weeks to test a simple correction. Take it easy. I take security threads serious. Think of beeing avoidable vulnerable for nearly three weeks is a pain in my stomach. Maybe you are right, you should switch to another O/S. I bet you they coordinate and delay disclosure as well. Or better yet, you can switch to MS, which you are lucky if you get a patch in 2 weeks time. M$, you are kidding ;) Look at it this way: Debian Security Team (DST) finds out about a security bug from an organization (let's say CERT for the sake of discussion). CERT asks Debian to prepare for release but delay disclosure until further notice so all the CERT Coordinated Vendors (I believe Debian is one) can get on board. Debian decides to go against CERT and release immediately after the fix is made. CERT then decides they will no longer tell DST in advance since they breached trust. DST then finds out about the vulnerability the same time the rest of the world does. DST then rushes about (after the announcement) to put together a package and release a DSA. By now they are several hours or a day behind everyone else. Would you still prefer DST ignore coordinated release schedules? If so...perhaps you are correct...you could switch to a different O/S or Distro. Let's see: RedHatGoing Commercial..hope you have a deep pocket book. (BTW, they obey coordinated releases also). FedoraStill in it's infancy and organizing from the RedHat break off. Mandrake...They have Coordinated releases too. Any other distrodo they have security releases? But the dominance of the CERT is excactly the point I'm criticising. Even it is necessary to coordinate the sec affords - imho fixies should be applied if they are ready and not if some organisation say so. Anyhow, please sit back, take a few deep breaths and stop throwing such a stink. ok. May I ask you what local / remote root exploit-fixes are you holding back currently? Should I switch of my sshd for the next few days or does the current bash have an unfixed local root exploit? Not worth answering Please don't take it serious - it was meant to be ironic. I beg you pardon, if you are insulted by that. This is exactly the same policy M$ have - but the point is, you could at least inform your users. Yes, inform the users, let the ENTIRE hack community know, don't provide a fix. Then the release coordinator (CERT) gets mad at you...see above. How is this any better? This is not what I'm talking about - unfixed vuln. must be held back. An unknown local root exploit was one of the key parts in the debian server compromise and we have all seen the consequences. Yes, it was. There are probably several hundred unknown local root exploits. The source code is open, why not put your words into action and start finding some flaws? I neither have the knowlegde nor the time for doing that. But the point at is, that these vuln. are not avoidable at the moment - the last has been avoidable for nearly three weeks. Surely, you can see, that I want to keep this risk as small as possible on my servers. I do also. well, it seems, that we agreed at last ;) Keep smiling yanosz -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iQIVAwUBQDPmqNAHMQ8GQaYRAQJRPA//QsTfQrTC4AS6TGwZMQz6mo2t+0TI5Ulq 93bquRnk+mXSYTgOoOC925YJ5O5Vj/9qUMqk8aQq0LQx5g+qOM31vTKRCUBY8XIp aWuVXiL1iMvncwJGURzyweew0QHb1RYsl7zr9RMZS2M1QwxdfnI2INcevwaBUG3n QDUnxWAokSxkNMRDlojaFEzzlW3iFauVrzPqr1AfO0+xv78mi6YGxBVvLIWbx/0S lw0yc2Pm0Cd3YzSFx5tqKortMeTYt1rkiCyPPlq/uCSLoIygtHrII4N/IuBPKFMW I3xAuNs2cHM92V33Oac4juUs7j35jaQecEZPNKQZ0QPp4pgcSSQ2Mda56/bNC0sl SzjLJPiVN6akLx4naxssmF2Rw61J/Z9PiEXnwX2/kc6gCs2y4+s5SFY8FKnyIjVe 7tBdilImLMt63CgdRRb332Ji3MNXjmdx8lbyJep0wHvvixslAwhfKjkv0bV/6+lB r+7c2bQ5uOvWS+TXZg9GCVeuBH2l8tRcWnuN7OWfV7H5XdAWGZ6ewVxgg6Vf2FFC bgqJ79PMDHFj8/zBmihedefKXu06qGQs/4tCBqQH3xKmgsArmSvsfxLx4CFfB5/X J6Bt66N2S58ZMkrRp+wiQqkFrI24euAPcHxQLloi2zSYuItilMF3/Stqkedgr/09 BSms9+Cean8= =Sp85 -END PGP SIGNATURE-
Re: DSA 438 - bad server time, bad kernel version or information delayed?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings, Am Mittwoch, 18. Februar 2004 22:47 schrieb Michael Stone: On Wed, Feb 18, 2004 at 10:36:35PM +0100, Jan Lühr wrote: Well, of course you might have quite good reasons for doing so, but for me, this is quite a good reason for changing the distri or os. Goodbye. Hiding unfixed holes is one thing (and I appreciate that partly) but hiding already fixed packages is quite astonishing and you cannot tell me you need more than two weeks to test a simple correction. I don't think anyone in a position to tell you such a thing did so. If you want to amuse yourself by wild unfounded speculation that's your prerogative, but I have to say that approach is likely to find you pissing in the wrong stream. Ok, I thing your are right here. But if knowlegde about this vuln is availeable - if fixes are done, but not avaible yet, how do I protect myself? Keep smiling yanosz -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iQIVAwUBQDPpJdAHMQ8GQaYRAQKAZQ//c4YYJ0x5a1k7sN2xj+S8uAoe2tYOFkW4 uUHdEChXnDWHfvs/JiNWItWLUuFcKVSHcYH5v3g3nkGusDLZesrnXH1e6KL7Qu3B kKElVfpmDhWRVZ8zdUJhKRUa9kwdZZKAMlXC/bYiPqyaIOZCHg0VwXZurcCOanOR epuJSomXVvL+wL2SIAkg/AbZvhtTEf5cHqoYjnuf4QnGUyPkFEHNz9UuU8XLv7ot zQjDWCP6b7M4y4XClwOFjeTcGEqUuF/mg9QzDuyw6lZgI9it3XMW6g786uGGY9TT Ss3DzPNxikuZBxBesH7Q2Ue+UQm9Ym87OQZ6+YYsW/XCIDIE8tyC/N8+elMTr7kh kYntDX/D0UHwPNagiWdLWoOoibl07EU35z6S891np0Hku0nOhQDP/g6e5vgeqrMN 7VRjEmig/wHCRALh1OiBJGv4FfofZZt8wjr9xZZ66W1/vbpi4LaBv/+MTQoGf1p7 thVY9MSKDbCjKVwMiWRYN5AogoFXR/Gr6Xx1cWzWaveGaIxyAGFNVZ71HLarX0qt jT4U5cy9Qo0NdtgTHPy9BOWRH4DOyeZMaD+bqdmr1P8OoaZGue/RXq+fzNvgdG29 kpvg0jRVQBpVJQT4JCt2vHOb49twplCC2U4k+E9e50gmD2sqP3qpnHH0P5irmEqP mgEUYQM7l9c= =nFoY -END PGP SIGNATURE-
[OT] Re: Infrastructer back online?
Greetings, On Sat, Januar 10 2004 at 04:22 Matt Zimmerman wrote: On Sat, Jan 10, 2004 at 03:22:15AM +, Nick Boyce wrote: On Wed, 7 Jan 2004 19:43:02 -0800, Matt Zimmerman wrote: On Thu, Jan 08, 2004 at 04:08:23AM +0100, Martin Helas wrote: Am Mi Jan 07, 2004 at 06:5432 -0800 gab Matt Zimmerman [EMAIL PROTECTED] von sich: On Wed, Jan 07, 2004 at 10:35:30PM +0100, Jan L??hr wrote: noticing the increasing amount of secure-adv I'd like to ask, wheter the buid-deamons are back or wheter another issue is increasing the amount of advs rapidly. Everything is working again. what's about p.d.o ? There is more than one p.d.o and only one of them is not operational. That has nothing to do with security, thankfully. Erm .. people.debian.org is back online, though some people seem to be missing from it. And packages.debian.org is still offline, Any guesses when he is inspected to be only again? Is it going to to take days or weeks? Keep smiling yanosz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[OT] Re: Infrastructer back online?
Greetings, On Sat, Januar 10 2004 at 04:22 Matt Zimmerman wrote: On Sat, Jan 10, 2004 at 03:22:15AM +, Nick Boyce wrote: On Wed, 7 Jan 2004 19:43:02 -0800, Matt Zimmerman wrote: On Thu, Jan 08, 2004 at 04:08:23AM +0100, Martin Helas wrote: Am Mi Jan 07, 2004 at 06:5432 -0800 gab Matt Zimmerman [EMAIL PROTECTED] von sich: On Wed, Jan 07, 2004 at 10:35:30PM +0100, Jan L??hr wrote: noticing the increasing amount of secure-adv I'd like to ask, wheter the buid-deamons are back or wheter another issue is increasing the amount of advs rapidly. Everything is working again. what's about p.d.o ? There is more than one p.d.o and only one of them is not operational. That has nothing to do with security, thankfully. Erm .. people.debian.org is back online, though some people seem to be missing from it. And packages.debian.org is still offline, Any guesses when he is inspected to be only again? Is it going to to take days or weeks? Keep smiling yanosz
Infrastructer back online?
Greetings, noticing the increasing amount of secure-adv I'd like to ask, wheter the buid-deamons are back or wheter another issue is increasing the amount of advs rapidly. Keep smiling yanosz
