Re: SSH
Hi, From: Phillip Hofmeister Date: Mon, 16 Dec 2002 17:52:15 -0500 I am sure you have seen the SSH CERT. Are we vulnerable? If so is there a time line for an update? I'd like to know too -- perhaps there's a chance the Debian package (the OpenSSH-based one) isn't vulnerable as OpenSSH 3.5 and earlier is listed at: http://www.rapid7.com/advisories/R7-0009.txt as APPARENTLY NOT VULNERABLE.
ethereal 0.9.6?
Hi folks, I presume many of you have heard of the following: http://www.ethereal.com/appnotes/enpa-sa-6.html Is the Debian package affected?
Re: Bug#149714: libfam0 Does not depend on fam
Hi, From: Cedric Ware [EMAIL PROTECTED] Subject: Re: Bug#149714: libfam0 Does not depend on fam Date: Sun, 18 Aug 2002 02:30:02 +0200 I do use dselect and have no use for a local famd, and am somewhat annoyed by this change in stable. (I have a vague recollection that dependencies in stable should not change, but I can't find anything about it in policy, so I must be mistaken.) Please add me to the list of annoyed people (-; Well, I'm not sure about how not to do it since, as you say, dselect does now pester about it. If famd is not to run locally, one must either use 'Q' to tell dselect to really not touch it - which, for all intents and purposes, defeats the dependencies - or comment it in /etc/inetd.conf, but AFAIG there is no guarantee that a future upgrade of the fam package will not reactivate it. Or is there a better way? I'd like to know the answer to this question as well.
Re: Bug#149714: libfam0 Does not depend on fam
Hi, From: Henrique de Moraes Holschuh [EMAIL PROTECTED] Subject: Re: Bug#149714: libfam0 Does not depend on fam Date: Mon, 19 Aug 2002 08:54:54 -0300 On Mon, 19 Aug 2002, [EMAIL PROTECTED] wrote: purposes, defeats the dependencies - or comment it in /etc/inetd.conf, but AFAIG there is no guarantee that a future upgrade of the fam package will not reactivate it. I didn't write the above -- though I think I have been bitten by this kind of thing for one package in the past. File a serious bug on fam if it ever overrides your local configuration automatically. This is Not Allowed. I think the point trying to be made here is not that such a thing would be done intentionally, but that: it might not be too unlikely to happen through error -AND- it's in a package that we didn't want to install any way -AND- we don't know of a way to easily prevent this package from being installed if using dselect [1]. So, if the libfam* packages had to be changed, it would be nice to have a better way to deal w/ this type of situation. May be there is one -- if there is, please let us know! (-; [1] Having to use Q EVERY time we use dselect to prevent the package from being installed may eventually lead to pilot error.
opie: configuring server to use particular hash
Hi, I'm trying to get opie-server|libpam-opie to use sha1 instead of md5, but I haven't figured out how to do this on the server end. For the client end, the -s option seems to be what to use w/ opiekey (though this doesn't appear to be in the man pages...). Has anyone figured out how to get this to work? (The man pages in the .debs seem to be a bit dated and I didn't manage to find any other relevant documentation.)
Re: Some more port closing questions
Hi, From: Paul Hampson [EMAIL PROTECTED] Subject: Re: Some more port closing questions Date: Thu, 1 Aug 2002 20:17:10 +1000 On Thu, Aug 01, 2002 at 07:09:28AM +0900, [EMAIL PROTECTED] wrote: From: Phillip Hofmeister [EMAIL PROTECTED] Subject: Re: Some more port closing questions Date: Wed, 31 Jul 2002 10:49:44 -0400 On Wed, 31 Jul 2002 at 09:25:40PM +0900, [EMAIL PROTECTED] wrote: Perhaps update-rc.d or rcconf (as I posted earlier) can be used to get the desired behavior -- but I do think that being asked by default at installation time whether to start stuff up at boot time is better behavior than the current behavior. Boy...you should get together withthe folks on debian-devel that say the install asks TOO many questions for a beginner to Linux...it would make a good flame war G It seems like you could just have a mode w/o many/any questions and a mode that asks all the questions that are available -- i.e. Beginners can have a beginner's mode of installation, and non-beginners can have a non-beginner installation mode...no? You mean like maybe assigning different questions different priorities, and letting the user choose the priority which a question needs to have before it is asked, with some default assumed otherwise? No. Nice description of what exists currently (-; I just mean something you choose at the beginning of the installation process to circumvent the entire question asking process -- I'm not asking for this -- perhaps I should learn not to respond to comments in posts w/ Gs in them... Excellent idea. I can't see how we could get this far without such a system. ;-) Nice sarcasm (-;
Re: [SECURITY] [DSA-136-1] Multiple OpenSSL problems
Hi, From: Paul Baker [EMAIL PROTECTED] Subject: Re: [SECURITY] [DSA-136-1] Multiple OpenSSL problems Date: Thu, 1 Aug 2002 20:04:24 -0500 On Thursday, August 1, 2002, at 06:35 PM, [EMAIL PROTECTED] wrote: You might find the checkinstall package to be of some use here. It's worked quite nicely for most things I've tried it for. That would be more of the quick short cut way of doing it which always seems to byte you in the ass later (perhaps when sarge is released). Also it expects you to be installing software that has 'make install' etc. Which our software doesn't necessarily have either. So as part of turning everything into debian packages, they will also get nice shiny Makefiles. Ah well. Good luck in any case.
Re: service enablement via mail and otp?
Hi, From: Karl E. Jorgensen [EMAIL PROTECTED] Subject: Re: service enablement via mail and otp? Date: Thu, 1 Aug 2002 01:20:46 +0100 ... I wrote: I've downloaded a copy and taken a quick look at the man page -- I didn't notice anything about mechanisms for dealing w/ replay attacks in the man page -- are there any? No. I have to admit that I hadn't even thought about replay attacks :-(. I'll have to see what methods others have employed to avoid them (or think up a probably-less-secure method myself). Right. There are a few obvious ones that come to mind: -Get an appropriate time stamp [1] and include that in the request -- the server can keep the stamp around for some time after completing the request and delete after some period of time. The server can be configured to only execute requests that have valid time stamps that have times w/in a certain distance compared to the current time. Presumably you want a time stamp that can't be or is extremely difficult to forge -- you need a way of verifying it too. For various reasons (e.g. existing technologies, complexity, etc.), I don't think this approach is currently doable -- a full discussion would be way off-topic and long, so I think we should steer clear of this. -Challenge-response: server sends a challenge in encrypted form, you decrypt it and include it in your encrypted reply. The server checks this and has a mechanism for checking whether it has already processed a request w/ that challenge in the past. [ It's nice to employ a method that doesn't require keeping around a lot of state information. ] The reason I like the OTP design for my particular situation is that I don't want to carry around a PGP key [1] and I don't want to mess w/ doing some kind of round-trip-challenge-response thing via mail to deal w/ potential replay attacks. Hm... GPG *does* have a --symmetric option, which seems to not use keys at all. Assuming that a suitable method for generating (and keeping-in-sync) passphrases between your PDA and smash, do you think that would be suitable for you? This probably implies storing/generating acceptable passphases locally (for smash) in clear-text... Hmmm, I'm not sure what you mean here. When you say not use keys I presume you mean doesn't use public key crypto keys but does use symmetric key crypto keys... One of the nice things about OTPs (as per the IETF RFCs) is that there is a calculation mechanism (based on a common seed) that's simple and fast enough to be implemented on many PDAs. You can store the seed in encrypted form on your PDA and only decrypt it when you need to calculate some OTPs. ... But it should be reasonably simple to add extensions to check the script immediately before execution. I'd prefer to implement such extensions as separate scripts. I like that idea. One more on my TODO list. (-; [1] I've got OTP calculators for my PDA which I'm fine w/ carrying. Actually, what I don't want is to carry around a secret key and a corresponding device to do the encryption/signing/decryption (perhaps some day PDAs will do this comfortably). I'm not about to place a secret key of mine on someone else's machine... Which OTP calculator (and PDA) do you use? I've got a PDA too, and this might be handy for me too... [ This is probably OT for this list...] I use a Palm-compatible device. The OTP calculator I've been using is pilOTP. I've also tried PalmKey and Pilot/OTP, but I remember experiencing a bug in one of them and I don't remember what problem I had w/ the other. IIRC, either Keyring or Strip (but not both) has some kind of OTP support too. P.S. Feel free to mail me directly for further discussion. [1] Much harder than one might imagine (-;
service enablement via mail and otp?
Hi, For some time, I've been toying w/ the idea of putting together something that would allow me to trigger the starting/stopping of various services [1] via a mail message containing some kind of OTP. It seems like a fairly straightforward thing to implement but I'm not itching to maintain any code, so I was hoping there was something out there that does this already. I've looked around a bit but haven't turned up anything -- does anyone here know of anything similar out there already? [1] Specifically, I'm thinking that sshd might be a nice thing to have off most of the time on some of my systems.
Re: Some more port closing questions
Hi, From: Mathias Palm [EMAIL PROTECTED] Subject: Re: Some more port closing questions Date: Wed, 31 Jul 2002 11:23:55 +0200 On Wed, Jul 31, 2002 at 08:24:50AM +0900, [EMAIL PROTECTED] wrote: Hi, From: Rick Moen [EMAIL PROTECTED] Subject: Re: Some more port closing questions Date: Tue, 30 Jul 2002 16:21:18 -0700 Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]): Kind of off-topic here, but I've been wondering for a while [1] whether the portmap package would be made to not install by default. I'd been wondering the same thing. Beyond that, I've been hoping that, at some point in the future, Debian won't cause network daemons to autostart in the default runlevel just because they've been installed. E.g., maybe the dpkg --configure step could prompt for that decision. Ah, that would be nice too. I know that the first thing I usually do when I boot my laptop is to stop a bunch of daemons that started up at boot (-; Apart from the starting by default issue: Why not just remove the appropriate symlinks S* in the directory /etc/rc2.d/ (or whatever runlevel you get into by default). Keep the scripts in /etc/init.d so you can start them by hand later. I used to do this but after a while I got tired of doing it manually and having to think about the implementation details of runlevels (i.e. the S* and K* stuff). It's really an interface issue (apart from the default issue). On a related note, I just ran dselect and noticed rcconf -- may be that's what I want (-; I'll have to check that out.
Re: Some more port closing questions
Hi, From: Frank Copeland [EMAIL PROTECTED] Subject: Re: Some more port closing questions Date: Wed, 31 Jul 2002 10:33:37 + (UTC) On 30 Jul 02 23:24:50 GMT, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Ah, that would be nice too. I know that the first thing I usually do when I boot my laptop is to stop a bunch of daemons that started up at boot (-; # update-rc.d -f somedaemon remove From update-rc.d(8), I take it this: removes any links in the /etc/rcrunlevel.d directories to the script /etc/init.d/name. The script must have been deleted already - update-rc.d checks for this. I don't think that's what I want -- I want the software installed, just not started by default. I believe it's not that uncommon to install some software for testing purposes (at least this is often the case for me) -- in this kind of situation, you don't necessarily want the software to be running all of the time. In addition, if you're using a laptop which you power on and off w/ regular frequency (such as a few times a day), all daemons starting up at boot presents an inconvenient situation. Relying on myself to turn things off whenever I boot is prone to error and writing custom scripts to automate this is not a good practice from a maintenance perspective. IMHO it really ought to be part of the OS' capabilities. Perhaps update-rc.d or rcconf (as I posted earlier) can be used to get the desired behavior -- but I do think that being asked by default at installation time whether to start stuff up at boot time is better behavior than the current behavior. I particularly like NetBSD's approach of not enabling any network daemons by default -- it requires an explicit decision on the part of the system administrator to have a network daemon start up. Just me two cents (-;
Re: Some more port closing questions
Hi, From: Thomas J. Zeeman [EMAIL PROTECTED] Subject: Re: Some more port closing questions Date: Wed, 31 Jul 2002 14:55:25 +0200 (CEST) On Wed, 31 Jul 2002 [EMAIL PROTECTED] wrote: Hi, From: Frank Copeland [EMAIL PROTECTED] Subject: Re: Some more port closing questions Date: Wed, 31 Jul 2002 10:33:37 + (UTC) On 30 Jul 02 23:24:50 GMT, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Ah, that would be nice too. I know that the first thing I usually do when I boot my laptop is to stop a bunch of daemons that started up at boot (-; # update-rc.d -f somedaemon remove From update-rc.d(8), I take it this: removes any links in the /etc/rcrunlevel.d directories to the script /etc/init.d/name. The script must have been deleted already - update-rc.d checks for this. I don't think that's what I want -- I want the software installed, just not started by default. [snip] The -f takes care of that. It makes the update-rc.d ignore the check for an init-script in /etc/init.d Thanks for pointing that out (-;
Re: Some more port closing questions
Hi, From: Phillip Hofmeister [EMAIL PROTECTED] Subject: Re: Some more port closing questions Date: Wed, 31 Jul 2002 10:49:44 -0400 On Wed, 31 Jul 2002 at 09:25:40PM +0900, [EMAIL PROTECTED] wrote: Perhaps update-rc.d or rcconf (as I posted earlier) can be used to get the desired behavior -- but I do think that being asked by default at installation time whether to start stuff up at boot time is better behavior than the current behavior. Boy...you should get together withthe folks on debian-devel that say the install asks TOO many questions for a beginner to Linux...it would make a good flame war G It seems like you could just have a mode w/o many/any questions and a mode that asks all the questions that are available -- i.e. Beginners can have a beginner's mode of installation, and non-beginners can have a non-beginner installation mode...no? Frankly, I don't like have to answer the same questions over and over though -- I'm hoping the automated installation procedures improve so I can just use those (I'm not complaining mind you). In the mean time, I've found that partimage is finally usable for my current situation (-;
Re: Some more port closing questions
Hi, From: Javier Fernández-Sanguino Peña [EMAIL PROTECTED] Subject: Re: Some more port closing questions Date: Wed, 31 Jul 2002 15:00:51 +0200 On Wed, Jul 31, 2002 at 09:25:40PM +0900, [EMAIL PROTECTED] wrote: I don't think that's what I want -- I want the software installed, just not started by default. (...) FYI: http://www.debian.org/doc/manuals/securing-debian-howto/ch3.en.html#s3.6 I wonder why I wrote it? :) It's a nice explanation of the current state of things, isn't it? Did you read what I wrote about testing and have you noticed the comments about starting by default issue? I wonder why I wrote some of them? (-; Seriously though, I think in this case it comes down to a difference in philosophy. I'll just shut up and make do.
Re: service enablement via mail and otp?
Hi, From: Karl E. Jorgensen [EMAIL PROTECTED] Subject: Re: service enablement via mail and otp? Date: Wed, 31 Jul 2002 13:47:16 +0100 On Wed, Jul 31, 2002 at 02:01:14PM +0200, Marcin Owsiany wrote: On Wed, Jul 31, 2002 at 01:37:30PM +0900, [EMAIL PROTECTED] wrote: Hi, For some time, I've been toying w/ the idea of putting together something that would allow me to trigger the starting/stopping of various services [1] via a mail message containing some kind of OTP. Recently I have seen someone posting an URL to his program which does something like that. It used GPG. I can't find the post, but I think you could find it looking for keywords like mail execution remote etc.. I guess it was this list, but I'm not sure. That someone could have been me: http://www.karl.jorgensen.com/smash Note: This is not production quality (yet). I use it myself on a couple of machines and find it useful. Testers and bugreports are welcome. Eyes on the source to find security weaknesses are in high demand. Read the man-page. Caveat Emptor. This could be nice...too nice for me perhaps (-; I've downloaded a copy and taken a quick look at the man page -- I didn't notice anything about mechanisms for dealing w/ replay attacks in the man page -- are there any? The reason I like the OTP design for my particular situation is that I don't want to carry around a PGP key [1] and I don't want to mess w/ doing some kind of round-trip-challenge-response thing via mail to deal w/ potential replay attacks. I'm also more comfortable w/ only allowing limited command execution -- specifically, only starting a single-session-only sshd (perhaps stopping sshd too) -- so that worse case, someone can only start sshd on a machine I'm looking after. Any plans for limiting the commands to be executed? [1] I've got OTP calculators for my PDA which I'm fine w/ carrying. Actually, what I don't want is to carry around a secret key and a corresponding device to do the encryption/signing/decryption (perhaps some day PDAs will do this comfortably). I'm not about to place a secret key of mine on someone else's machine...
Re: Some more port closing questions
Hi, From: Ruben Porras [EMAIL PROTECTED] Subject: Re: Some more port closing questions Date: 30 Jul 2002 20:50:42 +0200 On Tue, 2002-07-30 at 19:09, Crawford Rainwater wrote: Thanks to all on the Portsentry issue I had a week ago. Along those same lines, I have two ports I cannot figure out (even looking through the LDP) on how to close or shut down their related services. They are as follows: 111/tcp sunrpc 111/udp sunrpc I think you can just unistall portmap to close this two ports. Probably you don't need it. Kind of off-topic here, but I've been wondering for a while [1] whether the portmap package would be made to not install by default. Not likely I suppose. [1] Since before it became its own package actually...I'd been hoping it would be made its own package and then not installed by default...
Re: Some more port closing questions
Hi, From: Rick Moen [EMAIL PROTECTED] Subject: Re: Some more port closing questions Date: Tue, 30 Jul 2002 16:21:18 -0700 Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]): Kind of off-topic here, but I've been wondering for a while [1] whether the portmap package would be made to not install by default. I'd been wondering the same thing. Beyond that, I've been hoping that, at some point in the future, Debian won't cause network daemons to autostart in the default runlevel just because they've been installed. E.g., maybe the dpkg --configure step could prompt for that decision. Ah, that would be nice too. I know that the first thing I usually do when I boot my laptop is to stop a bunch of daemons that started up at boot (-;
Re: Can you direct kernel messages?
Hi, From: Dale Amon [EMAIL PROTECTED] Subject: Re: Can you direct kernel messages? Date: Tue, 23 Jul 2002 12:44:10 +0100 On Tue, Jul 23, 2002 at 06:13:46PM +0700, Jean Christophe ANDR?? wrote: There is also direct console kernel loging. You can reduce by using dmesg (man dmesg = -n option). Thanks. That did it. I've been trying to track that down for months. Never would have thought of dmesg in a million years. I'd never have thought of it either -- which shows I hadn't examined the first sentence of dmesg(8) in detail: dmesg is used to examine or control the kernel ring buffer. ^^^ ! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: woody ssh update and PAM keyboard-interactive authentication won't work.
Hi, From: Rolf Kutz [EMAIL PROTECTED] Subject: Re: woody ssh update and PAM keyboard-interactive authentication won't work. Date: Sat, 6 Jul 2002 12:26:54 +0200 * Quoting Chuck Peters ([EMAIL PROTECTED]): It doesn't appear as though this keyboard-interactive authentication is something we want or need, but I don't know what it means and I haven't found anything in the ssh or sshd man pages or the libpam-doc that explains what it means. Would someone please point me to appropriate documentation or explain what is PAM keyboard-interactive authentication? One Time Passwords e.g. (libpam-opie). But could be any PAM challenge-response dialog. Does anyone know whether there's any chance this can/will get fixed in the future? I had been planning to use opie stuff on some machines so that when I didn't have my private key for remote access, I'd be able to log in from a terminal which I didn't trust too much. It seems a real shame not to be able to use this functionality... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: woody ssh update and PAM keyboard-interactive authentication won't work.
Hi, Thanks for the response. From: Rolf Kutz [EMAIL PROTECTED] Subject: Re: woody ssh update and PAM keyboard-interactive authentication won't work. Date: Sun, 7 Jul 2002 03:48:11 +0200 * Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]): From: Rolf Kutz [EMAIL PROTECTED] One Time Passwords e.g. (libpam-opie). But could be any PAM challenge-response dialog. Does anyone know whether there's any chance this can/will get fixed in the future? You can use opie if you turn off privilege separation. Right. This reduces some security while opie might add some, depending on your situation. Despite the aggravation of the upgrade process this time around, I actually think privilege separation is a good idea and am hoping that other daemons may also follow suit where appropriate. So, I'd prefer to leave it on. I read somewhere, that they work on a fix, but it could take a while. Thanks for this info -- if you happen to come across the reference again, I'd appreciate it if you could pass it along. Thanks! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CERT Advisory CA-2002-19 Buffer Overflow in Multiple DNS Resolver Libraries
Hi, From: Florian Weimer [EMAIL PROTECTED] Subject: Re: CERT Advisory CA-2002-19 Buffer Overflow in Multiple DNS Resolver Libraries Date: Fri, 05 Jul 2002 12:20:06 +0200 [EMAIL PROTECTED] writes: Ah, I see your in-depth post on Bugtraq now (-; http://msgs.securepoint.com/cgi-bin/get/bugtraq0207/39/1.html From your Bugtraq post, I got the impression that since I haven't changed the defaults in /etc/nsswitch.conf -- i.e. my networks: line is: networks: files I shouldn't have anything to worry about at the moment. Does that sound right? Yes, you don't have to worry about any of the problems which have been published so far (no, I don't know of any other problems). Great! Thanks for taking the time to make the clarification. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
ethereal 0.9.4 - 0.9.5?
Hi, I noticed a number of days back at ethereal's home page that a new version (0.9.5) was released that has some security fixes since the release of 0.9.4: http://www.ethereal.com/appnotes/enpa-sa-5.html I also noticed a 0.9.5 package in unstable (whose changelog.Debian.gz file mentions the security fixes), but I haven't seen an announcement on debian-security-announce for this (nothing via email and I don't see anything in the online archives for debian-security or debian-security-announce either). Is there some an announcement on the way? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CERT Advisory CA-2002-19 Buffer Overflow in Multiple DNS Resolver Libraries
Hi, Thanks for the comments. Ah, I see your in-depth post on Bugtraq now (-; http://msgs.securepoint.com/cgi-bin/get/bugtraq0207/39/1.html From your Bugtraq post, I got the impression that since I haven't changed the defaults in /etc/nsswitch.conf -- i.e. my networks: line is: networks: files I shouldn't have anything to worry about at the moment. Does that sound right? I presume though that updated libc6 packages are being worked on -- Can anyone comment on this? P.S. This recent string of problems: Apache chunk OpenSSH libc resolver / BIND mod_ssl Samba (haven't seen this in English news yet) in such a short period is the worst (in the sense of each of the problems being in fairly widely used packages and the problems being serious) I've experienced in my 7-8 years of system administration. I've been dreading what the rest of summer vacation has in store for us... From: Florian Weimer Subject: Re: CERT Advisory CA-2002-19 Buffer Overflow in Multiple DNS Resolver Libraries Date: Thu, 04 Jul 2002 08:40:31 +0200 [EMAIL PROTECTED] writes: I see a claim that glibc isn't vulnerable at: http://www.kb.cert.org/CERT_WEB/vul-notes.nsf/id/AAMN-5BMSW2 Any comments? GNU libc in its current version does contain incorrect code from BIND 4.9. It is vulnerable, though not in the way initially described by PINE-CERT. However, most vendors (including, for example, OpenBSD) have fixed the same vulnerability while adressing the main issues raised by PINE-CERT. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CERT Advisory CA-2002-19 Buffer Overflow in Multiple DNS Resolver Libraries
[Trying again w/ an attempt to graft on to an existing thread.] Hi, I see a claim that glibc isn't vulnerable at: http://www.kb.cert.org/CERT_WEB/vul-notes.nsf/id/AAMN-5BMSW2 Any comments? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CERT Advisory CA-2002-19 Buffer Overflow in Multiple DNS Resolver Libraries
Hi, I see a claim that glibc isn't vulnerable at: http://www.kb.cert.org/CERT_WEB/vul-notes.nsf/id/AAMN-5BMSW2 Any comments? (Sorry about breaking the thread -- I only just recently subscribed and don't have the messages in this thread in my mailer) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
