Re: Dropping syn+fin replies, but not really?
Eirik Øverby [EMAIL PROTECTED] writes: I have a FreeBSD based firewall (pfsense) and, behind it, a few dozen FreeBSD servers. Now we're required to run external security scans (nessus++) on some of the hosts, and they constantly come back with a high or medium severity problem: The host replies to TCP packets with SYN+FIN set. Problem: Both the firewall (FreeBSD 6.2-based pfSense 1.2) and the host in question (recent FreeBSD 7.2-PRERELEASE) have net.inet.tcp.drop_synfin=1 - I would therefore expect this to be a non- issue. I added drop_synfin for one reason and one reason only: it prevented nmap from reliably identifying a FreeBSD machine, and at the time, that was sufficient to ward off the kind of script kiddies that would regularly attack EFNet IRC servers. I don't think SYN+FIN packets were ever a security issue, and I'm surprised Nessus thinks they are. Perhaps someone read about drop_synfin and misunderstood its purpose? Back to the issue at hand: you should use tcpdump to double-check nessus's findings. Who knows, perhaps drop_synfin was broken in a network stack reorganization. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dropping syn+fin replies, but not really?
On Nov 23 17:03:15, Eirik ?verby wrote: I have a FreeBSD based firewall (pfsense) and, behind it, a few dozen FreeBSD servers. Now we're required to run external security scans (nessus++) on some of the hosts, and they constantly come back with a high or medium severity problem: The host replies to TCP packets with SYN+FIN set. Aparently, nessus thinks that replying to SYNFIN packets at all is a problem. But it thinks so because you configured it to thinks so, right? Or is this hardwired into nessus? Also, why would nessus sometimes think that it's a high severity problem, and at other times, it's a medium severity problem? Problem: Both the firewall (FreeBSD 6.2-based pfSense 1.2) and the host in question (recent FreeBSD 7.2-PRERELEASE) have net.inet.tcp.drop_synfin=1 - I would therefore expect this to be a non- issue. It you configured your firewall and servers to NOT reply to SYNFIN packets, and the still do, then this is a configuration issue itself. How you also checked with other tools to find whether your servers reply to SYNFIN, or do you trust nessus who says so? Jan ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ports/129097: [vuxml] print/hplip: document CVE-2008-2940 and CVE-2008-2941
On Monday 24 November 2008, Eygene Ryabinkin wrote: Anish, good day. That's fine, thanks. But yesterday I had sent a patch that fixes the vulnerabilities for 2.8.2. What do you think about it? Could you test the patch? The VuXML entry details depend on this: I wrote that hplip = 2.8.4 aren't vulnerable, but if you'll approve the patch that upgrades to 2.8.2_3, then VuXML entry should be corrected. Thanks again! Finally got a around to it. The patches look fine, and it passed my basic testing. Commit. Thanks, -- Anish Mistry [EMAIL PROTECTED] AM Productions http://am-productions.biz/ signature.asc Description: This is a digitally signed message part.
[vuxml] editors/vim: document netrw issues
Submitter-Id: current-users Originator:Eygene Ryabinkin Organization: Code Labs Confidential: no Synopsis: [vuxml] editors/vim: document netrw issues Severity: serious Priority: medium Category: ports Class: sw-bug Release: FreeBSD 7.1-PRERELEASE i386 Environment: System: FreeBSD 7.1-PRERELEASE i386 Description: A bunch of vulnerabilities were discovered in Vim: http://www.rdancer.org/vulnerablevim-netrw.html http://www.rdancer.org/vulnerablevim-netrw.v2.html http://www.rdancer.org/vulnerablevim-netrw.v5.html http://www.rdancer.org/vulnerablevim-netrw-credentials-dis.html Some of them affect Vim =7.0 and 7.2. How-To-Repeat: Look at the above URLs and read Jan Lieskovsky summary: http://www.openwall.com/lists/oss-security/2008/10/16/2 Fix: The following VuXML entry should be evaluated and added: --- vuln.xml begins here --- vuln vid= topicvim -- multiple vulnerabilities in the netrw module/topic affects package namevim/name namevim-lite/name namevim-gtk2/name namevim-gnome/name rangege7.0/gelt7.2/lt/range /package /affects description body xmlns=http://www.w3.org/1999/xhtml; pJan Minar reports:/p blockquote cite=http://www.rdancer.org/vulnerablevim-netrw.v2.html; pApplying the ``D'' to a file with a crafted file name, or inside a directory with a crafted directory name, can lead to arbitrary code execution./p /blockquote blockquote cite=http://www.rdancer.org/vulnerablevim-netrw.v5.html; pLack of sanitization throughout Netrw can lead to arbitrary code execution upon opening a directory with a crafted name./p /blockquote blockquote cite=http://www.rdancer.org/vulnerablevim-netrw-credentials-dis.html; pThe Vim Netrw Plugin shares the FTP user name and password across all FTP sessions. Every time Vim makes a new FTP connection, it sends the user name and password of the previous FTP session to the FTP server./p /blockquote /body /description references urlhttp://www.rdancer.org/vulnerablevim-netrw.html/url urlhttp://www.rdancer.org/vulnerablevim-netrw.v2.html/url urlhttp://www.rdancer.org/vulnerablevim-netrw.v5.html/url urlhttp://www.rdancer.org/vulnerablevim-netrw-credentials-dis.html/url mlisthttp://www.openwall.com/lists/oss-security/2008/10/16/2/mlist cvenameCVE-2008-3076/cvename /references dates discovery2008-10-16/discovery entrytoday/entry /dates /vuln --- vuln.xml ends here --- ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ports/129037: [patch] [vuxml] graphics/imlib2: fix CVE-2008-5187
Synopsis: [patch] [vuxml] graphics/imlib2: fix CVE-2008-5187 State-Changed-From-To: open-closed State-Changed-By: stas State-Changed-When: Mon Nov 24 17:50:36 UTC 2008 State-Changed-Why: Committed, with minor changes. Thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=129037 ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-08:11.arc4random
| By FreeBSD Security Advisories [EMAIL PROTECTED] | [ 2008-11-24 19:48 +0200 ] III. Impact All security-related kernel subsystems that rely on a quality random number generator are subject to a wide range of possible attacks for the 300 seconds after boot or until 64k of random data is consumed. The list includes: I suppose this would affect the quality of SSH host keys generated at boot time by RC? Thanks, Aragon ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-08:11.arc4random
Upon reading this, my first question was whether the weakness applies to the random numbers supplied by /dev/random. If it does, then userspace has been getting non-random values, and things like PGP and SSH keys could be compromised. It might be good for secteam to clarify this, IMHO. On Mon, 24 Nov 2008, FreeBSD Security Advisories wrote: FreeBSD-SA-08.11.arc4random Security Advisory The FreeBSD Project ... -- Nate Eldredge [EMAIL PROTECTED] ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to [EMAIL PROTECTED]
ANNOUNCE: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-08:11.arc4random
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 = FreeBSD-SA-08.11.arc4random Security Advisory The FreeBSD Project Topic: arc4random(9) predictable sequence vulnerability Category: core Module: sys Announced: 2008-11-24 Credits:Robert Woolley, Mark Murray, Maxim Dounin, Ruslan Ermilov Affects:All supported versions of FreeBSD. Corrected: 2008-11-24 17:39:39 UTC (RELENG_7, 7.1-PRERELEASE) 2008-11-24 17:39:39 UTC (RELENG_7_0, 7.0-RELEASE-p6) 2008-11-24 17:39:39 UTC (RELENG_6, 6.4-STABLE) 2008-11-24 17:39:39 UTC (RELENG_6_4, 6.4-RELEASE) 2008-11-24 17:39:39 UTC (RELENG_6_3, 6.3-RELEASE-p6) CVE Name: CVE-2008-5162 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit URL:http://security.FreeBSD.org/. I. Background arc4random(9) is a generic-purpose random number generator based on the key stream generator of the RC4 cipher. It is expected to be cryptographically strong, and used throughout the FreeBSD kernel for a variety of purposes, some of which rely on its cryptographic strength. arc4random(9) is periodically reseeded with entropy from the FreeBSD kernel's Yarrow random number generator, which gathers entropy from a variety of sources including hardware interrupts. During the boot process, additional entropy is provided to the Yarrow random number generator from userland, helping to ensure that adequate entropy is present for cryptographic purposes. II. Problem Description When the arc4random(9) random number generator is initialized, there may be inadequate entropy to meet the needs of kernel systems which rely on arc4random(9); and it may take up to 5 minutes before arc4random(9) is reseeded with secure entropy from the Yarrow random number generator. III. Impact All security-related kernel subsystems that rely on a quality random number generator are subject to a wide range of possible attacks for the 300 seconds after boot or until 64k of random data is consumed. The list includes: * GEOM ELI providers with onetime keys. When a provider is configured in a way so that it gets attached at the same time during boot (e.g. it uses the rc subsystem to initialize) it might be possible for an attacker to recover the encrypted data. * GEOM shsec providers. The GEOM shsec subsytem is used to split a shared secret between two providers so that it can be recovered when both of them are present. This is done by writing the random sequence to one of providers while appending the result of the random sequence on the other host to the original data. If the provider was created within the first 300 seconds after booting, it might be possible for an attacker to extract the original data with access to only one of the two providers between which the secret data is split. * System processes started early after boot may receive predictable IDs. * The 802.11 network stack uses arc4random(9) to generate initial vectors (IV) for WEP encryption when operating in client mode and WEP authentication challenges when operating in hostap mode, which may be insecure. * The IPv4, IPv6 and TCP/UDP protocol implementations rely on a quality random number generator to produce unpredictable IP packet identifiers, initial TCP sequence numbers and outgoing port numbers. During the first 300 seconds after booting, it may be easier for an attacker to execute IP session hijacking, OS fingerprinting, idle scanning, or in some cases DNS cache poisoning and blind TCP data injection attacks. * The kernel RPC code uses arc4random(9) to retrieve transaction identifiers, which might make RPC clients vulnerable to hijacking attacks. IV. Workaround No workaround is available for affected systems. V. Solution NOTE WELL: Any GEOM shsec providers which were created or written to during the first 300 seconds after booting should be re-created after applying this security update. Perform one of the following: 1) Upgrade your vulnerable system to 6-STABLE, or 7-STABLE, or to the RELENG_7_0, or RELENG_6_3 security branch dated after the correction date. 2) To patch your present system: The following patches have been verified to apply to FreeBSD 6.3 and 7.0 systems. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. [FreeBSD 7.x] # fetch http://security.FreeBSD.org/patches/SA-08:11/arc4random.patch # fetch http://security.FreeBSD.org/patches/SA-08:11/arc4random.patch.asc [FreeBSD 6.x] # fetch http://security.FreeBSD.org/patches/SA-08:11/arc4random6x.patch # fetch
Re: ports/129037: [patch] [vuxml] graphics/imlib2: fix CVE-2008-5187
2008/11/24 [EMAIL PROTECTED]: Synopsis: [patch] [vuxml] graphics/imlib2: fix CVE-2008-5187 State-Changed-From-To: open-closed State-Changed-By: stas State-Changed-When: Mon Nov 24 17:50:36 UTC 2008 State-Changed-Why: Committed, with minor changes. Thanks! I can see no need for this on the Freebsd-security mailinglist. It amounts to spam. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ports/128999: [vuxml] [patch] update audio/streamripper to 1.64.0, fix CVE-2008-4829
2008/11/23 [EMAIL PROTECTED]: Synopsis: [vuxml] [patch] update audio/streamripper to 1.64.0, fix CVE-2008-4829 Can we not have these on the freebsd-secuirty list please? I subscribe to freebsd-security to get security alerts, not to get emails every time a port is changed. William Palfreman ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dropping syn+fin replies, but not really?
On Nov 23, 2008, at 18:52, Pieter de Boer wrote: Eirik Øverby wrote: I have a FreeBSD based firewall (pfsense) and, behind it, a few dozen FreeBSD servers. Now we're required to run external security scans (nessus++) on some of the hosts, and they constantly come back with a high or medium severity problem: The host replies to TCP packets with SYN+FIN set. I'd consider this at most a 'low' severity problem. Agreed. Problem: Both the firewall (FreeBSD 6.2-based pfSense 1.2) and the host in question (recent FreeBSD 7.2-PRERELEASE) have net.inet.tcp.drop_synfin=1 - I would therefore expect this to be a non-issue. Given security tools' (including Nessus') track records of false positives, I wouldn't be surprised if this was one of them. They generate a lot of others, too, mostly due to insufficient or downright bogus identification of services. Since when did pound ssl proxy equal aladdin web server? And since when was it common to run Apache 2.0.23 for Linux on FreeBSD 7.0? Not to mention all the windows- specific vulnerabilities I'm supposedly open to. Have I missed something important? Apart from this the hosts and services get away without any serious issues, but the security audit company insists this so-called hole to be closed. It's not a hole, but could possibly aid in bypassing filtering rules (which is quite unlikely in this day and age). It may be wise to find a security company that knows how to interpret and verify Nessus output. If you want to do verification yourself, you could try the following: - Run tcpdump on one of the servers and on the firewall - Run nmap from an external host using the '--scanflags SYNFIN' flag with destination the server. You can let tcpdump only show specific ports and source/destination addresses. It's probably useful to use nmap to scan both ports you know to be open and in use and ports that are filtered. Using the -p option to nmap, you can specify which ports to scan. Perform the nmap scan and look at the tcpdump output to see how your firewall and/or server react. nmap command: nmap -PN -sT --scanflags SYNFIN -pport anduin.net where port was either 80 (open) or 8585 (closed). tcpdump command on firewall (which NATs to internal IPs): tcpdump -i interface -p -vvv host alge.anart.no and \(port 80 or port 8585\) where interface was the publicly facing interface on the firewall. Results for port 80: IP (tos 0x0, ttl 59, id 12785, offset 0, flags [DF], proto: TCP (6), length: 64) alge.anart.no.40283 213.225.74.230.http: S, cksum 0xa720 (correct), 3300467486:3300467486(0) win 16384 mss 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 2747936488 0 IP (tos 0x0, ttl 63, id 10914, offset 0, flags [DF], proto: TCP (6), length: 60) 213.225.74.230.http alge.anart.no.40283: S, cksum 0x8ef5 (correct), 347647336:347647336(0) ack 3300467487 win 65535 mss 1460,nop,wscale 3,sackOK,timestamp 2946365534 2747936488 IP (tos 0x0, ttl 59, id 33877, offset 0, flags [DF], proto: TCP (6), length: 52) alge.anart.no.40283 213.225.74.230.http: ., cksum 0x7dbd (correct), 1:1(0) ack 1 win 16384 nop,nop,timestamp 2747936488 2946365534 IP (tos 0x0, ttl 59, id 31905, offset 0, flags [DF], proto: TCP (6), length: 40) alge.anart.no.40283 213.225.74.230.http: R, cksum 0x7180 (correct), 1:1(0) ack 1 win 0 Results for port 8585: IP (tos 0x0, ttl 59, id 44156, offset 0, flags [DF], proto: TCP (6), length: 64) alge.anart.no.1839 213.225.74.230.8585: S, cksum 0xf765 (correct), 1324215952:1324215952(0) win 16384 mss 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 4070158112 0 IP (tos 0x0, ttl 63, id 34488, offset 0, flags [DF], proto: TCP (6), length: 40) 213.225.74.230.8585 alge.anart.no.1839: R, cksum 0x52ef (correct), 0:0(0) ack 1324215953 win 0 I can't tell what's going on here, except I wouldn't have expected a reply at all to the second one at least, and maybe not even the first. However, I don't have enough experience to tell if nmap is doing the right thing here at all. Thanks, /Eirik___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dropping syn+fin replies, but not really?
Hi Eirik, Perform the nmap scan and look at the tcpdump output to see how your firewall and/or server react. nmap command: nmap -PN -sT --scanflags SYNFIN -pport anduin.net where port was either 80 (open) or 8585 (closed). tcpdump command on firewall (which NATs to internal IPs): tcpdump -i interface -p -vvv host alge.anart.no and \(port 80 or port 8585\) where interface was the publicly facing interface on the firewall. Results for port 80: IP (tos 0x0, ttl 59, id 12785, offset 0, flags [DF], proto: TCP (6), length: 64) alge.anart.no.40283 213.225.74.230.http: S, cksum 0xa720 (correct), 3300467486:3300467486(0) win 16384 mss 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 2747936488 0 IP (tos 0x0, ttl 63, id 10914, offset 0, flags [DF], proto: TCP (6), length: 60) 213.225.74.230.http alge.anart.no.40283: S, cksum 0x8ef5 (correct), 347647336:347647336(0) ack 3300467487 win 65535 mss 1460,nop,wscale 3,sackOK,timestamp 2946365534 2747936488 Results for port 8585: IP (tos 0x0, ttl 59, id 44156, offset 0, flags [DF], proto: TCP (6), length: 64) alge.anart.no.1839 213.225.74.230.8585: S, cksum 0xf765 (correct), 1324215952:1324215952(0) win 16384 mss 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 4070158112 0 IP (tos 0x0, ttl 63, id 34488, offset 0, flags [DF], proto: TCP (6), length: 40) 213.225.74.230.8585 alge.anart.no.1839: R, cksum 0x52ef (correct), 0:0(0) ack 1324215953 win 0 I can't tell what's going on here, except I wouldn't have expected a reply at all to the second one at least, and maybe not even the first. However, I don't have enough experience to tell if nmap is doing the right thing here at all. First of all, this is not a scan with both the SYN and FIN flags set. This can be seen from the tcpdump output only showing the 'S' flag. You're using -sT, which makes nmap use connect(), and thus the regular SYN, SYN/ACK, ACK 3-way-handshake. For a SYN/FIN scan, you'll need root access. I tested this locally without supplying further TCP scan options to nmap. Could you retest and make sure you see 'SF' as flags in tcpdump? Secondly, it would be useful if you'd explain the following: is your firewall NATting port 8585 also, or is traffic sent to that port handled by the TCP/IP stack of the firewall itself? Furthermore, it appears the firewall is not actually filtering traffic to port 8585.. The strictest firewall configuration would be to have everything filtered except the ports you actually use. Those ports are either NATted to the back-end system or handled by the firewall itself (in case you want that functionality). From a security perspective, simply dropping incoming traffic is better than sending back RST's. In pf this is the default. Regards, Pieter ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-08:11.arc4random
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 24 Nov 2008 10:07:18 -0800 (PST) Nate Eldredge [EMAIL PROTECTED] mentioned: Upon reading this, my first question was whether the weakness applies to the random numbers supplied by /dev/random. If it does, then userspace has been getting non-random values, and things like PGP and SSH keys could be compromised. It might be good for secteam to clarify this, IMHO. Userland applications are unaffected ssh keys included. /dev/[u]?random receives entropy from Yarrow, not from arc4random and feeded with saved entropy upon boot by /etc/rc.d/initrandom. Only kernel services that rely on arc4random(9) is vulnerable. - -- Stanislav Sedov ST4096-RIPE -BEGIN PGP SIGNATURE- iEYEARECAAYFAkkrI2cACgkQK/VZk+smlYGvrwCfTEuy+4AIk/b6l6bxRX0tcVs0 PZMAniLO3ltjq5232cErhAtB7u5SJI4J =UmVN -END PGP SIGNATURE- ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ports/128999: [vuxml] [patch] update audio/streamripper to 1.64.0, fix CVE-2008-4829
On 11/24/08 19:55, William Palfreman wrote: 2008/11/23 [EMAIL PROTECTED]: Synopsis: [vuxml] [patch] update audio/streamripper to 1.64.0, fix CVE-2008-4829 Can we not have these on the freebsd-secuirty list please? I subscribe to freebsd-security to get security alerts, not to get emails every time a port is changed. William Palfreman You should better head over to security-advisories@ if you're only interested in SA's. Claiming about reading security related issues on a security mailing list sounds like fun. I appreciate Eygenes' work. Volker ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ports/128999: [vuxml] [patch] update audio/streamripper to 1.64.0, fix CVE-2008-4829
On Mon, Nov 24, 2008 at 11:06:56PM +0100, William Palfreman wrote: That's nice. I am sure it is very useful on the ports mailinglist where it belongs. I also greatly enjoy the frequent interesting and informed discussion on the security mailinglist - of which Eirik Overby's thread recently about syn+fin is one example. But all these ports announcements, raw patches, garbled html etc. I could really do without. It is why there are separate lists. Was there a discussion or even an announcement indicating that the security-related port commit messages would be sent to freebsd-security? This seems to have started just this month. Like William, I also find the explosion of commit messages and bug tracking minutia detracts from the low volume and high value of the freebsd-security list. The list description on mailman indicates the intent of the list is to be a 'high-signal, low-noise discussion of issues affecting the security of FreeBSD.' Including every single obliquely security related port commit seems counter to this intention. I'd very much like to see a separate list for the automated port postings, leaving this list to it's historical usage. David ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ports/128999: [vuxml] [patch] update audio/streamripper to 1.64.0, fix CVE-2008-4829
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 You should better head over to security-advisories@ if you're only interested in SA's. Claiming about reading security related issues on a security mailing list sounds like fun. I appreciate Eygenes' work. I also appreciate this work, but I agree that I don't think it's appropriate for [EMAIL PROTECTED] It's much too noisy, and makes it harder to see real discussion in amongst the noise. If people really would like to see these kind of notifications (i.e., security-related PRs for ports) in mailing-list format, I think that a separate mailing list would be appropriate (e.g., freebsd-security-ports@). Thanks as always to the security team for their fine work. -Jason -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) Comment: See https://private.idealab.com/public/jason/jason.gpg iD8DBQFJKypWswXMWWtptckRAnxBAJ4lbTt4DzBwrfJQ9BMwUlNqY/b23gCfSN6u XUSM49KMxTBvBBDc6T12EOA= =98ll -END PGP SIGNATURE- ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-08:11.arc4random
On Mon, 24 Nov 2008 10:07:18 -0800 (PST) Nate Eldredge [EMAIL PROTECTED] wrote: Upon reading this, my first question was whether the weakness applies to the random numbers supplied by /dev/random. If it does, then userspace has been getting non-random values, and things like PGP and SSH keys could be compromised. It might be good for secteam to clarify this, IMHO. I'm not from secteam, but I did submit the problem and suggest the solution. The primary problem is that the kernel version of arc4random is seeded from yarrow before yarrow itself is seeded. This does not affect /dev/random or userland arc4random, just the things mentioned in the advisory. However, there is a second problem that is fixed by the patch, but not documented in the advisory. Closing a write to /dev/random causes a yarrow reseed, but previously didn't flush the entropy queue first. The first 4kB of low-grade entropy that's fed into /dev/random before the entropy file causes the queue to saturate, leaving no space for the entropy file, which is tail-dropped. And without a flush any entropy in the queues isn't processed into the yarrow key until another reseed occurs, at which point it's redundant anyway. In short, the primary entropy file didn't previously do anything useful. Whether that's actually a problem isn't clear to me. On my desktop machine yarrow reseeds by itself before the entropy file is used, due to disk activity. There may however be some platforms where the entropy file is really needed, and /dev/random itself may have been a bit insecure until the stage in the boot process where /var is mounted and the secondary entropy files in /var/db/entropy/ are used. PGP and SSH keys are generated late in the boot process, or after boot, usually on machines with plenty of entropy, so there shouldn't be an issue there. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ports/128999: [vuxml] [patch] update audio/streamripper to 1.64.0, fix CVE-2008-4829
On Mon, Nov 24, 2008 at 5:06 PM, William Palfreman [EMAIL PROTECTED]wrote: 2008/11/24 Volker [EMAIL PROTECTED]: On 11/24/08 19:55, William Palfreman wrote: 2008/11/23 [EMAIL PROTECTED]: Synopsis: [vuxml] [patch] update audio/streamripper to 1.64.0, fix CVE-2008-4829 Can we not have these on the freebsd-secuirty list please? I subscribe to freebsd-security to get security alerts, not to get emails every time a port is changed. William Palfreman You should better head over to security-advisories@ if you're only interested in SA's. Claiming about reading security related issues on a security mailing list sounds like fun. I appreciate Eygenes' work. That's nice. I am sure it is very useful on the ports mailinglist where it belongs. I also greatly enjoy the frequent interesting and informed discussion on the security mailinglist - of which Eirik Overby's thread recently about syn+fin is one example. But all these ports announcements, raw patches, garbled html etc. I could really do without. It is why there are separate lists. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED] you do know that the email your complaining about is about a security update correct? if you don't like it then you really need to use security-advisories instead of being subscribed to this one ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PR followups in the freebsd-security list [WAS: ports/129037: [patch] [vuxml] graphics/imlib2: fix CVE-2008-5187]
William, everyone, good day.
Mon, Nov 24, 2008 at 08:05:26PM +0100, William Palfreman wrote:
2008/11/24 [EMAIL PROTECTED]:
Synopsis: [patch] [vuxml] graphics/imlib2: fix CVE-2008-5187
State-Changed-From-To: open-closed
State-Changed-By: stas
State-Changed-When: Mon Nov 24 17:50:36 UTC 2008
State-Changed-Why:
Committed, with minor changes. Thanks!
I can see no need for this on the Freebsd-security mailinglist. It
amounts to spam.
Sorry for this. I used to put freebsd-security@ to the X-GNATS-Notify
field of the PR, so followups were slipping to this list.
Since the very last Sunday (or Saturday, don't remember well ;)), I am
putting freebsd-security@freebsd.org to the CC field of the original PR.
Thus, only initial posting will go into the list. I hope that such
approach will be better for the list and its subscribers. If this still
won't be a satisfying decision, I can completely drop freebsd-security@
from the PR recipients, but in this case I could miss some important
feedback from the community and I want to avoid this, if it will be
possible.
Once again, sorry for the noise. Old PR's will still produce some
amount of follow-ups, but the new ones shouldn't do it anymore.
While I am here: thanks for the appreciation of my work that was
expressed by the people in the list ;))
Thanks for your patience!
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgpsZ4vHgzF7I.pgp
Description: PGP signature
