xfree86 4.2.1-9, cve CAN-2003-0063 and CAN-2003-0071
According to http://packages.qa.debian.org/x/xfree86/news/1.html xfree86 4.2.1-9 fixes some security issues (just in xterm?) along with doing some other things. Drew Daniels -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
xfree86 4.2.1-9, cve CAN-2003-0063 and CAN-2003-0071
According to http://packages.qa.debian.org/x/xfree86/news/1.html xfree86 4.2.1-9 fixes some security issues (just in xterm?) along with doing some other things. Drew Daniels
Announcement: APT Secure
The original anouncment was on debian-devel and can be seen in the archives here: http://lists.debian.org/debian-devel/2003/debian-devel-200306/msg01655.html To: Debian Developers [EMAIL PROTECTED] Subject: Announcement: APT Secure From: Isaac Jones [EMAIL PROTECTED] Date: Thu, 26 Jun 2003 10:30:02 -0400 Message-id: [EMAIL PROTECTED] Old-return-path: [EMAIL PROTECTED] User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) Greetings :) APT Secure is the working name of a project to add to APT the ability to verify the authenticity of Debian packages. It accomplishes this via a chain of trust which is initiated by the package maintainers and ends on the installing machine. This is a call to the community to help test and audit this patch to APT, and to eventually participate in the policy discussion about the patch. Please see http://monk.debian.net/apt-secure/ for more information and to download Debian packages. There's also a mirror here: http://people.debian.org/~walters/monk.debian.net/ peace, Isaac Colin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Announcement: APT Secure
The original anouncment was on debian-devel and can be seen in the archives here: http://lists.debian.org/debian-devel/2003/debian-devel-200306/msg01655.html To: Debian Developers debian-devel@lists.debian.org Subject: Announcement: APT Secure From: Isaac Jones [EMAIL PROTECTED] Date: Thu, 26 Jun 2003 10:30:02 -0400 Message-id: [EMAIL PROTECTED] Old-return-path: [EMAIL PROTECTED] User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) Greetings :) APT Secure is the working name of a project to add to APT the ability to verify the authenticity of Debian packages. It accomplishes this via a chain of trust which is initiated by the package maintainers and ends on the installing machine. This is a call to the community to help test and audit this patch to APT, and to eventually participate in the policy discussion about the patch. Please see http://monk.debian.net/apt-secure/ for more information and to download Debian packages. There's also a mirror here: http://people.debian.org/~walters/monk.debian.net/ peace, Isaac Colin
[unconfirmed] new atftp vulnerabilities
I'm writing [unconfirmed] now when I've found new advisories or bugs but haven't had time to fully research them and see if they really are vulnerabilities and whether Debian is vulnerable (potato, woody, sarge, sid). It seems that since mdz has been put on the Security Team proper that he's released DSA's just after I find the bids or, advisories or speculation of bugs. This is likely co-incedental, but nice to see the spead at which advisories are released. http://www.securityfocus.com/bid/7902/discussion/ http://www.securityfocus.com/bid/7906/discussion/ http://www.securityfocus.com/bid/7907/discussion/ say: It should be noted that although this vulnerability has been reported to affect atftp version 0.7cvs, other versions might also be vulnerable. Without spending too much time on this I can say that I doubt the security advisory addresses these bid's which came out after it, and at least two of them are local buffer overflows which I'm not sure would even be vulnerabilities if atftp is not setup setuid/setgid... I also may have accidentaly included the bid that was fixed in the list of three. Drew Daniels -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[unconfirmed] new atftp vulnerabilities
I'm writing [unconfirmed] now when I've found new advisories or bugs but haven't had time to fully research them and see if they really are vulnerabilities and whether Debian is vulnerable (potato, woody, sarge, sid). It seems that since mdz has been put on the Security Team proper that he's released DSA's just after I find the bids or, advisories or speculation of bugs. This is likely co-incedental, but nice to see the spead at which advisories are released. http://www.securityfocus.com/bid/7902/discussion/ http://www.securityfocus.com/bid/7906/discussion/ http://www.securityfocus.com/bid/7907/discussion/ say: It should be noted that although this vulnerability has been reported to affect atftp version 0.7cvs, other versions might also be vulnerable. Without spending too much time on this I can say that I doubt the security advisory addresses these bid's which came out after it, and at least two of them are local buffer overflows which I'm not sure would even be vulnerabilities if atftp is not setup setuid/setgid... I also may have accidentaly included the bid that was fixed in the list of three. Drew Daniels
Ghostscript vulnerable (bid 7757)
http://www.securityfocus.com/bid/7757 says Debian Linux 2.2 has Aladdin Enterprises Ghostscript 5.10.10 and is vulnerable toan arbitrary command execution vulnerability. It lists cve CAN-2003-0354 and zfile.c... It says that the vulnerability was published May 17th, 2003. Is this really a vulnerability? Is Debian vulnerable to this bug? Drew Daniels -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Ghostscript vulnerable (bid 7757)
http://www.securityfocus.com/bid/7757 says Debian Linux 2.2 has Aladdin Enterprises Ghostscript 5.10.10 and is vulnerable toan arbitrary command execution vulnerability. It lists cve CAN-2003-0354 and zfile.c... It says that the vulnerability was published May 17th, 2003. Is this really a vulnerability? Is Debian vulnerable to this bug? Drew Daniels
atftpd vulnerability and patch?
http://packetstorm.linuxsecurity.com/filedesc/atftpdx.c.html says: Proof
of concept remote root exploit for atftpd version 0.6. Makes use of the
filename overflow found by Rick Patel. Related post here. Tested against
Debian 3.0. By gunzip
http://packetstorm.linuxsecurity.com/filedesc/atftpd.patch.html says:
Simple patch to fix the overflow found in atftpd by Rick Patel. By gunzip
The patch is:
--- tftpd_file.cTue Mar 12 05:26:18 2002
+++ tftpd_file_diff.c Thu Jun 5 20:31:06 2003
@@ -357,7 +357,8 @@
else
{
strcpy(filename, directory);
- strncat(filename, data-tftp_options[OPT_FILENAME].value, VAL_SIZE);
+ strncat(filename, data-tftp_options[OPT_FILENAME].value,
+ VAL_SIZE - strlen( directory ) - 1 );
}
/* If the filename contain /../ sequences, we forbid the access */
http://packages.qa.debian.org/a/atftp.html shows:
[2002-04-24] Accepted atftp 0.6.1.1 (source hppa)
[2002-04-13] Accepted atftp 0.6.1 (i386 source)
[2002-03-31] Accepted atftp 0.6 (i386 source)
[2002-02-11] Installed atftp 0.5 (i386 source)
[2001-07-21] Installed atftp 0.4 (i386 source)
[2001-03-05] Installed atftp 0.3 (i386 source)
[2000-12-27] Installed atftp 0.2 (i386 source)
[2000-08-21] Installed atftp 0.1 (source i386)
and:
Testing 0.6.1.1
Stable 0.6
I'm guessing atftp is vulnerable, but without checking I won't file a bug.
Checking the code should be easy, but checking if this could actualy be
exploited would take a bit more thought. If stable is actualy vulnerable
and exploitable then the security team should be co-ordinated with.
Drew Daniels
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
atftpd vulnerability and patch?
http://packetstorm.linuxsecurity.com/filedesc/atftpdx.c.html says: Proof
of concept remote root exploit for atftpd version 0.6. Makes use of the
filename overflow found by Rick Patel. Related post here. Tested against
Debian 3.0. By gunzip
http://packetstorm.linuxsecurity.com/filedesc/atftpd.patch.html says:
Simple patch to fix the overflow found in atftpd by Rick Patel. By gunzip
The patch is:
--- tftpd_file.cTue Mar 12 05:26:18 2002
+++ tftpd_file_diff.c Thu Jun 5 20:31:06 2003
@@ -357,7 +357,8 @@
else
{
strcpy(filename, directory);
- strncat(filename, data-tftp_options[OPT_FILENAME].value, VAL_SIZE);
+ strncat(filename, data-tftp_options[OPT_FILENAME].value,
+ VAL_SIZE - strlen( directory ) - 1 );
}
/* If the filename contain /../ sequences, we forbid the access */
http://packages.qa.debian.org/a/atftp.html shows:
[2002-04-24] Accepted atftp 0.6.1.1 (source hppa)
[2002-04-13] Accepted atftp 0.6.1 (i386 source)
[2002-03-31] Accepted atftp 0.6 (i386 source)
[2002-02-11] Installed atftp 0.5 (i386 source)
[2001-07-21] Installed atftp 0.4 (i386 source)
[2001-03-05] Installed atftp 0.3 (i386 source)
[2000-12-27] Installed atftp 0.2 (i386 source)
[2000-08-21] Installed atftp 0.1 (source i386)
and:
Testing 0.6.1.1
Stable 0.6
I'm guessing atftp is vulnerable, but without checking I won't file a bug.
Checking the code should be easy, but checking if this could actualy be
exploited would take a bit more thought. If stable is actualy vulnerable
and exploitable then the security team should be co-ordinated with.
Drew Daniels
New listing of security bugs
Colin Watson has written new code for the BTS to allow it to display bugs with certain tags, like security [1]. The new URL for bugs tagged security is http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=security and the old URL that's no longer linked to from qa.debian.org is still being updated at http://qa.debian.org/bts-security.html [1] http://lists.debian.org/debian-qa/2003/debian-qa-200305/msg00034.html Drew Daniels
Re: bug #80888: dnrd: Multiple buffer overflows
On Tue, 6 May 2003, Florian Weimer wrote: Drew Scott Daniels [EMAIL PROTECTED] writes: This bug may be worked around (and therefore downgraded) by having a configuration to warn the user that they must trust the DNS servers (wherever this is configured), and must trust the users. Are you sure that you only need to trust the DNS servers you contact, and not the entire DNS system? Some resolvers perform incomplete syntax checks on DNS packets. 8-( Unfortunately no I'm not sure. Actually it'd be nice to eliminate the need for trusting the DNS system. I guess a work around would require specifying trust is needed for the DNS system too, along with your explanation. One of the reasons stated for using DNRD was so that users didn't have to manually switch between /etc/resolv.conf's (or nameserver entries in there). autodns-dhcp, dnsmasq, laptop-netconf, guessnet, a DNS server (bind, bind9, djbdns-installer, maradns, mydns, pdns, nsd...), a dhcp client, may be replacements, but do they replace all the desired functionality? pdnsd seems to be a better package that provides all the same features and more, but I haven't looked too deep into either. There may be no (significant) reason to keep dnrd in the Debian archive. Note: Messages to [EMAIL PROTECTED] and Brad Garcia [EMAIL PROTECTED] are not going through. To post a message on the dnrd mailing list one needs to be subscribed, and I'm getting 550 5.1.2 [EMAIL PROTECTED]... Host unknown (Name server: home.com: no data known). Drew Daniels
bug #80888: dnrd: Multiple buffer overflows
Sorry for the crosspost, but I wanted to include everyone potentially interested in this bug. The home page for dnrd [1] seems to indicate that it is intended for use for a single computer or an internal network. The typical user will likely only want to allow input to dnrd from trusted sources [2]. This bug may be worked around (and therefore downgraded) by having a configuration to warn the user that they must trust the DNS servers (wherever this is configured), and must trust the users. To allow the ladder to be effective, configuration of who is allowed to query dnrd is needed too (default none allowed? configure allowed users through an inetd implementation?). This package however seems to be orphaned [3] and has another RC bug [4], so it may be worth removing this package [5]. Aj suggested [6] that if the bugs are left as RC (not downgraded/fixed) then the package should be removed or at least put in experimental. Rats [7], splint [8], flawfinder [9] or other tools may be useful in finding the buffer overflows. If upstream wants I can give them the output from a few of these audit tools to use as a starting point to *fix* these bugs. [1] http://users.zoominternet.net/~garsh/dnrd/ [2] ISP DNS's, local users, local network users, but they might not always be trusted. [3] http://packages.qa.debian.org/d/dnrd/news/1.html lists the only change as * Orphaned, set maintainer to Debian QA Group [4] Bug #189978: dnrd_2.10-7(unstable/ia64): FTBFS: warning treated as error http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=189978 [5] I dislike it when packages are removed, but if no one fixes or creates workarounds to downgrade RC bugs... [6] http://lists.debian.org/debian-release/2003/debian-release-200304/msg00024.html [7] http://www.securesoftware.com/auditing_tools_download.htm [8] http://www.splint.org/ [9] http://www.dwheeler.com/flawfinder/ Drew Daniels
Security Audit tools
http://serg.cs.drexel.edu/phpnuke/html/modules.php?name=Projectpa=showprojectpid=1 lists Bunch which is an interesting tool to show modularity. I haven't yet tried it. Also on this site they link to CoSAK which is an interesting newer security audit tool set. Has anyone tried these tools? Drew Daniels
Re: mgetty vulnerable
On Fri, 2 May 2003, Wolfgang Sourdeau wrote: I am not subscribed to debian-security, so please include me in your Cc: for this discussion. Likewise. I have noticed a fax user was expected in mgetty-1.1.30 (never played with 1.1.29). The problem I have with that is that this user is required at build time (during the make install phase). Another problem is that Debian does not have such a user, although one used to exist temporarily for hylafax a couple of years ago. Now, hylafax is using uucp, so is pppd and every communication server package I know of in Debian. The problem here seems to be that mgetty's sendfax was running under used root. Now, if we use uucp (which I have modified mgetty 1.1.30 for last week), I don't see where the problem is. I don't see the point in requesting the creation of a user for one little program nor do I judge this compromise (using uucp) as a security issue. Please correct me if I am wrong though. http://www.securityfocus.com/bid/7302 lists some more information. I don't think Debian has this vulnerability either, but I haven't checked. Under Credits you can find a Gentoo and Redhat advisory. Are there any group or world readable directory issues as is suggested to me? I'm talking about for durring installation *and* in normal use. ps: now it seems Debian mgetty's sendfax is broken since 1.1.30, but this is another issue which will be fixed before next week. Off topic, but related... I've been having trouble with mgetty and vgetty for years now. I had it almost working they way I wanted, but then it answered the phone and wouldn't hang up... after that vgetty or mgetty couldn't answer the phone, even after reboot... but I haven't looked into this for a long time now and that box might have fs problems now. Drew Daniels
JRE JDK 1.4.1_02 vulnerable?
http://www.securityfocus.com/bid/7109 says Sun's JRE and Java SDKs versions less than 1.4.1_02 are vulnerable as well as IBM's JDK. The BID seems to indicate the vulnerability is in java.util.zip I'm not sure which versions of Java JRE's and SDKs are in Debian, but it seems to me that in Contrib there's an IBM JDK installer that might install an affected version. Can someone check into these? Don't contact [EMAIL PROTECTED] until you are confident that stable or oldstable is affected. Drew Daniels
mgetty vulnerable?
I don't know whether potato, woody, sarge and sid should have a security bug filed against them. According to http://packages.qa.debian.org/m/mgetty.html sid has version 1.1.30-1, sarge has version 1.1.28-5, and woody has version 1.1.27-4.1. Note that Debian packages contain changes. I have not looked to see if these changes might fix the issues, but they should be visible in the http://saens.debian.org/debian/pool/main/m/mgetty/ directory as the *.diff.gz files. Note that it looks like potato contains mgetty 1.1.21-3potato1 which is a version of mgetty that contains a security fix that fixes the Immunix reports that mgetty does not create temporary files in a secure manner, which could lead to a symlink attack. bug. I'd imagine this change would have been incorporated in later versions. The changelog for version 1.1.23-3 says: mgetty (1.1.21-3) stable; urgency=low * make mgetty-fax's postinst create /var/spool/fax/outgoing/.last_run to close a potential symlink exploit by members of the fax group that is otherwise possible until that file is created -- Philip Hands [EMAIL PROTECTED] Thu, 31 Aug 2000 19:05:13 +0100 I can't see a changelog for version 1.1.23-3potato1, so maybe this is the diff file for that. http://search.alphanet.ch/cgi-bin/search.cgi?msgid=20021125142338.E12094%40greenie.muc.demax_results=1type=longdomain=ml-mgetty says: [...] Security fixes / concept changes: * it's now possible to run faxrunq/faxrunqd (and thus sendfax) as non-root user * fax spool directories are no longer world-writeable, access is done via a suid helper program (suid to a special user ID, fax) * possible buffer overrun when calling cnd-program (if CallerName is too long) * $CALLER_ID, $CALLER_NAME and so on are sanitized before passing to shell (all quote characters and all non-printable characters are replaced by ) [...] Who should upgrade? * everbody who is using faxspool/faxrunq on a machine that is shared with other users that are not 100 per cent trustworthy * vgetty users with V.253 modems Distribution vendors: - I strongly urge you to upgrade to 1.1.29 - older versions are NOT safe if there are malicious users on the system and faxrunq/faxrunqd are in use. - The fax queue handling (faxspool, faxq-helper) needs a new user ID now (fax) which MUST own the fax queue directories and SHOULD NOT own anything else. The user ID is configured in the Makefile. - faxrunq/faxrunqd can run as user fax, but in that case the user needs access to the modem devices (via his primary group id). Watch out for log file access permissions if this is used! If anything is unclear, *please* talk to me before rolling out updated packages that might break things in funny ways. [...] Please don't mail [EMAIL PROTECTED] until you are reasonably cetain potato or woody are vulnerable. Drew Daniels
Injectso to help with libc upgrades?
http://packetstorm.linuxsecurity.com/filedesc/injectso-0.2.1.tar.html describes injectso, a tool that can be used to inject shared libraries into running processes on Linux (x86/IA32 and Sparc) Maybe I misunderstand, but might it not be also possible to use this to inject replacements for shared libraries too? I wonder if this or something like it could be used for libc6, zlib... and other shared library upgrades. I'm not sure if it works or if it could be used for this kind of purpose. I remember a restart of certain services was done in an older libc upgrade (I believe libc6 between potato and woody). I bring this up because recently there was some concern about glibc security updates not restarting programs which would leave them vulnerable until restart. Should I bring this to the attention of the glibc maintainer(s)? Perhaps a wishlist bug? Drew Daniels
phpsysinfo vulnerabilities
http://www.securityfocus.com/bid lists two bugs in phpsysinfo. I'm unsure as to whether Debian is affected. Can someone else check and file a bug if necessary? Thanks Drew Daniels
Proposed guidelines and procedure for Team to patch vulnerabilities
As promissed in http://lists.debian.org/debian-security/2003/debian-security-200304/msg00373.html I've written a rough plan... Bugs get filed using appropriate procedure then... The team to patch vulnerabilities finds the bugs and starts its procedure... I still need to work on the procedure, and I'm thinking up a better name for the team. Perhaps Debian Vulnerability Patch Team or alike... I imagine most people on this team won't be Debian Developers or else they'd be on the Debian Security Team so some effort in naming is needed not to overlap or take away from their efforts... It occures to me that many may be interested in joining this team just for ego, resume fodder, 1337ness... To make sure this doesn't interfere with anything I won't be putting together a roster. If I do give credit it will based upon information available to me such as valuable contributions to the BTS, the Security Team, maintainer(s) and/or mailing lists. I don't keep any metrics on how much I've helped out and I regard this as time consuming and perhaps a waste of time. I don't expect to do it for others, but it'd be nice if someone did it for me. I also don't think it would hurt for people to keep track of their own contributions, and how helpful they were... if you want me to acknowledge it you'll have to give references to what you've done. I may also dispute various metrics... I don't want to see time wasted on flames though (hopefully not flames by me, I don't intend to flame, and I don't like flame-bate). - Some guidelines: New security bugs should follow proper procedure. Read http://www.debian.org/security/faq and note that whenever a new security bug is found send an e-mail to [EMAIL PROTECTED] If it's public knowledge or an extremely low risk and/or low hazard vulnerability then maybe file a bug in the BTS and set Tags: security... Some co-ordination between vendors and upstream(s) may be nessisary before vulnerabilities should be made public. Be careful not to file bugs that are not in Debian packages [1]. The BTS should be proprly used. Read through the documentation at http://www.debian.org/Bugs/ Please use the Tags as much as possible (security, potato, woody, sarge, sid, patch...). Please check if stable (now woody) oldstable (now potato), unstable (aka sid) and Testing (now sarge) could be affected. Don't assume that it is or isn't based upon its version number alone [2]. Give maintainers and the security team time to fix bugs. The security team's timeline *might* be directed by their policy(?) [3] to issue a DSA, fix or not, within one week. Maintainers *may* be given a few days to respond before people should bother writing a patch, and after a patch is submitted it is recomended to wait a few more days for a responce [4]. After the wait is up talk to a Developer about doing an NMU [5] or do one if you are a Debian Developer. [1] Debian stable sometimes has security patches backported from newer version numbers. Also there may be differences in the Debian version (that should only be in the Debian diff file) and upstream (which should be the same as the orig source). Security scanner false positives should be filed if and when they occure (Eg, nessusd). [2] In additon to [1], sometimes vulnerabilities are only introduced in later versions. Check the differences in the source code if you can (it'll need to be done eventualy), and try to exploit yourself if an exploit is possible/available. [3] http://lists.debian.org/debian-devel/1999/debian-devel-199908/msg01933.html [4] http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-nmu-when [5] Acording to http://lists.debian.org/debian-mentors/2003/debian-mentors-200304/msg00392.html debian-mentors@lists.debian.org might be the best place to request an NMU, but for example, an apache NMU request might go to debian-apache. Another good example is requesting an NMU of a package like libdb in debian-perl as a libdb RC bug affects perl. Note NMU's usualy don't get seen for at least 7 days after uploaded. Is there a way for non-dd (non Debian Developers) to check incomming/delayed? - Some Resources: http://qa.debian.org/bts-security.html lists bugs in the BTS that are tagged security. http://packages.qa.debian.org http://bugs.debian.org The Debian archive (it's a bit confusing to me still). It has source for all distributions that have the package (except maybe some non-free). Note that potato didn't use the pool directory structure. http://www.steve.org.uk/Debian/ is one example of a security audit that this team might help support 3rd party security information sources: http://www.securityfocus.org especialy under BIDs http://packetstormsecurity.nl and it's many mirrors CERT, other advisory places (like mitre or iss), vendors like Mandrake, SUSE, RedHat... For human help with patches: Upstream (see the copyright and files in the source, other bugs, a search engine...) Maintainers [EMAIL PROTECTED] (they're overworked so don't push
Re: mysql update for Woody?
Are you referring to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=173337 (more info in DSA 212) or something else? Where did you get the information that said mysql was vulnerable? http://www.securityfocus.com/cgi-bin/sfonline/vulns.pl and some security scanners sometimes doesn't update their DB to say that special Debian version numbers are not affected. In fact it seems 6374 hasn't been updated. Can someone send an e-mail to [EMAIL PROTECTED] telling them which BIDs DSA 212 fixes? Drew Daniels
fakechroot
For those that missed it on Debian-devel, there's a patched version of fakeroot that does chroot too. You can read about it and better/worse alternatives in the thread at: http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg00747.html Drew Daniels
Re: Woody security updates
Woody CD updates afaik are only done when stable releases are done. See http://people.debian.org/~joey/stable.html for details. There are nightly builds of CD's for Sarge and Sid, but I don't think I've seen any such thing for stable or oldstable that includes security updates. The nightly builds can be found through the debian-boot mailing list or perhaps the debian-installer (d-i) web site ( http://people.debian.org/~mbc/di.html ). A further note, security updates for Potato are still being done (and will stop soon iirc), but no further releases will be done. Again see http://people.debian.org/~joey/stable.html for details. Drew Daniels
RE: SANS Alert - Snort Vulnerability - stil Vulnerabile ?
On Tue, Mar 11, 2003 at 06:53:48PM +0900, Hideki Yamane wrote: This was added to the SANS Advisory on Sendmail last week. I have not seen any news nor postings related to Snort with Debian and was wondering about the status of Snort in stable at this time. snort vulnerability was posted in BTS. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=183719 # but, yes, DSA have not been released yet. Is Woody version stil Vulnerabile to this serious security bug ? I believe so. I'm using the bug to track the issue. Currently it's tagged sarge and woody. Snort.org said the default distribution is vulnerable, and in the Debian diff I see no change to the affected sections (for both woody and sarge). I've informed the security team, but they're likely busy with other issues. A comment from them on the bug would be nice. Drew Daniels
exploit for (Debian's?) pfinger (fwd)
oops, wrong address. -- Forwarded message -- Date: Wed, 4 Dec 2002 08:06:00 -0600 (CST) From: Drew Scott Daniels [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: exploit for (Debian's?) pfinger I found an exploit on Packetstorm described as Pfinger v0.7.8 and below local root exploit. Tested on Red Hat 7.2 - 8.0, Debian 3.0, Slackware 8.0, FreeBSD-4.6 and OpenBSD-3.1. I cannot find pfinger in Debian. The exploit executes finger and not a program called pfinger so it's not the Pascal finger program. Does this exploit effect Debian? Is/was there a bug report for this? Drew Daniels -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
exploit for (Debian's?) pfinger (fwd)
oops, wrong address. -- Forwarded message -- Date: Wed, 4 Dec 2002 08:06:00 -0600 (CST) From: Drew Scott Daniels [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: exploit for (Debian's?) pfinger I found an exploit on Packetstorm described as Pfinger v0.7.8 and below local root exploit. Tested on Red Hat 7.2 - 8.0, Debian 3.0, Slackware 8.0, FreeBSD-4.6 and OpenBSD-3.1. I cannot find pfinger in Debian. The exploit executes finger and not a program called pfinger so it's not the Pascal finger program. Does this exploit effect Debian? Is/was there a bug report for this? Drew Daniels
