Re: A different proposal
On Thu, Apr 10, 2014 at 6:28 PM, Paul Hoffman wrote: > I have heard from others, less interested in self-aggrandizement than > Theo, that OpenSSL's malloc was significantly to blame. > OpenSSL's simplistic malloc implementation exacerbated the information exposure in this case, so you might well say that it had a hand in the _severity_ of the bug. Depending on your system malloc, using that instead may or may not have yielded any improvement (and in OpenBSD's case, it would have) -- but the cause was an incredibly silly programming bug that had nothing to do with malloc. I'll get to just how silly it was shortly. I'm not saying OpenBSD's is better, > I'll say that: OpenBSD's is better. :) On that note, re-reading my prior mail, i didn't mean to come off as unflattering toward OpenBSD's malloc. They did a pretty good job with it. > Amateurish failure to check the sanity of user-supplied input was to > > blame. > > Yes. > > > Idiotic, error-prone protocol specifications, written by > > non-programmers, were to blame. > > Not in this case. > I'm not sure how you came to this conclusion, but let me explain how i came to mine: The heartbeat protocol structure sits within the SSL3 record. In the code, you know the length of the data at this point. But instead of using the length of this data to determine the size of your payload, the spec _also_ makes the user supply his own length. This practice is error-prone, and i've seen it cause problems before (the SSH2 spec is also full of garbage like this -- in fact, observing a similar protocol in the SSH2 spec is precisely what led me to discover a remote-execution vulnerability in the cryptlib ssh code, circa 2006). Now, the spec tries to make up for this bizarre requirement by telling the programmer to discard the packet if the specified payload length is "too large", but this is essentially passing the buck: if the spec says, "the implementer MUST avoid all memory-related bugs," and the programmer introduces a bug, does this mean the spec authors are absolved because the program is non-compliant? The best way to avoid memory-related bugs is to avoid practices that commonly result in them. The apparent silliness of this bug then comes to a head when you realize that the programmer who introduced the heartbeat bug is the same person who wrote most of the heartbeat RFC. Updates to ports are inherently slower than patches from the OpenSSL team. > My point is not that either ports or distribution are "too slow" for > everyone: it is that if you are sure you need something faster than them, > there is another option. > I didn't claim that the ports update was or will be fast enough for everyone. What i was getting at was that if you want the new version, but a new port hasn't yet been released, you can update the port files in your local ports tree yourself; it takes a rudimentary knowledge of how the port system works. You are, quite literally, installing the most recent version from source (as you suggest), except that you get automatic package management. ari ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: Retiring portsnap [was MITM attacks against portsnap and freebsd-update]
On 4/10/2014 12:03 PM, David Noel wrote: > I found a few bugs in portsnap and freebsd-update that I'd like to > bring to the community's attention and hopefully recruit people to > help fix. I mentioned them to Colin (their author) a few years ago and > he agreed that they're issues that need to be addressed, but in the > time since neither he nor I have been able to get around to fixing > them. I'm hoping that someone reading this is able and willing to > pitch in. I've also taken this to secteam@, but no one there's made > any progress on them in the past 6 months so I figured it was time to > approach the broader community. Surely there's a benevolent sh-savvy > hacker out there who has time to take these on. They're pretty simple > fixes -- the functionality that's needed exists in the scripts > already, it just needs to be reused in a few key places. > > I also think it would be an appropriate time to discuss retiring portsnap. > [snip] > > With the inclusion of svnlite in 10 I think the valid question comes > up as to whether we really need the portsnap system or whether it > could be safely retired. Obviously if the conclusion of that > discussion is that we don't need it then these bug fixes would be > unnecessary. > > The reason I see for it to be retired is that subversion allows us to > easily and securely check out the ports tree. It's a one-line command: > `svn co https://...`. Keeping it up-to-date it is another one-liner: > `cd /usr/ports; svn update`. With the inclusion of svnlite in base, > the portsnap code and servers acting as mirrors become redundant and > seem like a waste of resources. Your report aside, I find portsnap to be far superior in security for ports and users. I wish it knew how to checkout source as well. 1. It only allows a secure checkout. You can't accidentally checkout svn:// or http://. 2. It blows away directories with updates. I've witnessed a trojaned ports checkout before. 'svn update' does not remove unexpected files, nor remove changes. Yes this is a decrease in usability when you've modified the file and want to keep the changes, but you can easily make a wrapper script to merge in your changes, or use SVN if you really want. 3. SVN too often gets into confusing situations on 'svn update' that require knowledge of how SVN works to resolve the conflict. Even I with my ~10 years of SVN experience I get confused often and frustrated when not even 'svn revert -R dir; svn up dir' will revert to the upstream version (I may have my example off, but that's the point, it's confusing.) 4. SVN asks the user to confirm the public key when first using the HTTPS repository. I worry this step will be done poorly by users. 5. SVN requires 'svn upgrade' sometimes, this is also confusing for users. 6. The way we do HTTPS is through mirrors only, if you pick the wrong mirror it's against hard for the user who doesn't know SVN to change to a different mirror. Portsnap already handles mirrors excellently by geo location. Teaching portsnap how to speak SVN, while still behaving the same, may cover my concerns. To be fair SVN does have its advantages: 1. Quicker updates for users. 2. Easier patch generation for PR submission. 3. Similarly, viewing your changes more easily. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: linux-f10-openssl
On 4/9/2014 5:15 PM, Ronald F. Guilmette wrote: > > Does this port (linux-f10-openssl) also need to be rebuilt/reinstalled? > No, but I did just update vuxml to reflect older vulnerabilities it does have. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: A different proposal
On Apr 10, 2014, at 12:36 PM, ari edelkind wrote: > On Thu, Apr 10, 2014 at 10:56 AM, Paul Hoffman wrote: > >> Quite right. It is reasonable to assume that, given what we now know about >> the memory allocation scheme in OpenSSL, that other bugs exist and will >> only be found by exploits. Thus, it is reasonable to assume that there will >> be future emergencies like Heartbleed related to bugs in OpenSSL. >> > > I'm guessing you read a popular post by Theo de Raadt that's been going > around. Sorry, but OpenBSD's bastardized memory allocation scheme would > not have solved this; OpenSSL's malloc implementation was not to blame > here. I have heard from others, less interested in self-aggrandizement than Theo, that OpenSSL's malloc was significantly to blame. I'm not saying OpenBSD's is better, just that I have heard from multiple sources that OpenSSL malloc-wrapping both hides some bugs and makes them hard to find with automated tools. > Amateurish failure to check the sanity of user-supplied input was to > blame. Yes. > Idiotic, error-prone protocol specifications, written by > non-programmers, were to blame. Not in this case. > OpenSSL's allocator, in this instance, > worked fine -- even if it isn't the optimal choice for all operating > systems. Maybe; I'm certainly not in a position to say either way. > If your reliance on OpenSSL bugs being fixed requires a fix at a rate >> faster than what the FreeBSD community provides, then you should not rely >> on the FreeBSD community. > > > Or just make sure that all of your running services link to the OpenSSL > library built from ports. While i'm not exactly thrilled with the prospect > of waiting a significant amount of time for a vulnerability in the base > distribution to be officially patched, relying on the base system for > something like that is a bit like taking a tank to the racetrack. Updates to ports are inherently slower than patches from the OpenSSL team. My point is not that either ports or distribution are "too slow" for everyone: it is that if you are sure you need something faster than them, there is another option. >> Install OpenSSL on your mission-critical systems from OpenSSL source, not >> from FreeBSD ports or packages. > > > This is a poor idea from a maintenance standpoint. Firstly, the ports > system was updated fairly quickly, ...but not necessarily quick enough for the people complaining about the response speed of the FreeBSD team... > but aside from that, updating an > existing port yourself to download and install the next version is usually > a trivial task. And you get package management for free. Again: the whole point of this thread are people who apparently need more speed, demanding that someone be paid to make things faster for them. --Paul Hoffman ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: A different proposal
On Apr 10, 2014, at 12:34 PM, Nathan Dorfman wrote: > On Thu, Apr 10, 2014 at 10:56 AM, Paul Hoffman wrote: >> If your reliance on OpenSSL bugs being fixed requires a fix at a rate faster >> than what the FreeBSD community provides, then you should not rely on the >> FreeBSD community. Install OpenSSL on your mission-critical systems from >> OpenSSL source, not from FreeBSD ports or packages. > > I really don't think one needs to go this far. The workaround provided > in the original OpenSSL advisory, recompiling with > -DOPENSSL_NO_HEARTBEATS, was directly applicable to FreeBSD. For > anyone unsure exactly where to effect that option, it was discussed on > this very list. Also posted on this list was a working patch > containing the actual fix, on Monday afternoon. That fixed *this* bug; earlier ones took actual patches. > So yes, if you want a fully tested, reviewed and supported fix, you > had to wait, but anyone in desperate need of an immediate fix had > options that didn't involve ditching FreeBSD's OpenSSL. I was not proposing ditching FreeBSD's OpenSSL when the next bug was found: I was proposing that you switch at your own speed before the next emergency. And I'm not proposing that's the best thing to do: I'm certainly not going to, I'm quite happy with the FreeBSD response. This is a different proposal than "someone should get paid to reduce my security timing issues". It is "I should take responsibility for my security timing issues". --Paul Hoffman ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: Missing binary package security updates?
On 4/10/2014 22:05, Bryan Drewery wrote: > On 4/10/2014 1:35 PM, Janne Snabb wrote: >> >> I think I have noticed binary package updates only about once a week. Is >> my observation correct? Why such an infrequent update cycle? If there is >> some real reason to build package updates so rarely, would it be >> possible to hasten the cycle whenever serious issues like CVE-2014-0160 >> are found? > > (I am involved in building the packages) > > Yes packages currently start building Tuesday night. It takes until > Saturday/Sunday for all release/arch to finish building. As each > release/arch is finished the packages are uploaded. I think there is also some misconceptions here. There are over 24,000 packages. Even with incremental building, one week's worth of changes forces between 7000 and 15000 packages to rebuild. I assume some people think that touching 300 packages in a week means only 300 packages need to be rebuilt, but the reality is that it's hundreds. Depending on the machines and how many there are, it could take multiple days to make packages for just one platform. If it takes two days and there are 4 platforms to build, that's 8 days right there. So the words "infrequent update cycle" I think is a signal that these parameters aren't understood. (Note, I am not involved in building FreeBSD packages) >> Right now pkgng binary packages are not really suitable for production >> use because of lacking essential security updates. (There should be a >> loud and clear warning about this in the Handbook if it stays this way?) What would make it better? Even if somebody designed a particular vulnerability so important that it merited an out of cycle build (and all the ripples that would cause) it is still looking at 2-3 days cycle, minimum. How many of these security updates are "essential and can't wait 7 days?". heartbleed doesn't happen every day... Depending on what is deemed acceptable, I can't envision how binary packages (a courtesy ultimately) can be made good enough from a security standpoint. John ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: Missing binary package security updates?
On 4/10/2014 1:35 PM, Janne Snabb wrote: > Hi, > > I recently started using the new fancy pkgng binary packages on some > machines that I maintain. I thought I could save a lot of time as I > would not need to keep compiling ports manually any more. > > Unfortunately it seems that it was not such a good idea: > > # date > Thu Apr 10 21:27:22 EEST 2014 > # pkg audit > openssl-1.0.1_9 is vulnerable: > OpenSSL -- Multiple vulnerabilities - private data exposure > CVE: CVE-2014-0076 > CVE: CVE-2014-0160 > WWW: http://portaudit.FreeBSD.org/5631ae98-be9e-11e3-b5e3-c80aa9043978.html > > 1 problem(s) in the installed packages found. > # pkg upgrade > Updating repository catalogue > Nothing to do > # > > This is on FreeBSD 8/i386. > > I think I have noticed binary package updates only about once a week. Is > my observation correct? Why such an infrequent update cycle? If there is > some real reason to build package updates so rarely, would it be > possible to hasten the cycle whenever serious issues like CVE-2014-0160 > are found? (I am involved in building the packages) Yes packages currently start building Tuesday night. It takes until Saturday/Sunday for all release/arch to finish building. As each release/arch is finished the packages are uploaded. I did want to expedite updating this package but was blocked by a number of things. I regret we did not, and will not, have a package available sooner for all release/archs. I have started an internal discussion on building packages more frequently for security updates. > > Right now pkgng binary packages are not really suitable for production > use because of lacking essential security updates. (There should be a > loud and clear warning about this in the Handbook if it stays this way?) > > Best Regards, > -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: MITM attacks against portsnap and freebsd-update
On 4/10/14, David Noel wrote: >> I'm not convinced that a rototil of the protocol and all the associated >> storage duplication is worth the effort. > > As far as portsnap is concerned I'm not convinced that ANY amount of > effort is worth it. That is why I was hoping to start a conversation > on the possibility of phasing it out. > >> It's better in my mind to commit one of the patches to sandbox gzip >> with Capsicum... > > Portsnap also passes un-verified files to tar, so that would need to > be patched too. > >> ...which will protect from everything except filling the >> disk by denying gunzip the ability to do anything but write to the file >> opened by the script. That will protect all gzip users. > > I agree that what you're proposing is probably the simplest solution, > but I'm not convinced that it would guarantee system security. Nothing > against Robert Watson, but sandboxes are always being broken out of. > There's a history of vulnerabilities in the jail subsystem, isn't it > likely that someone some day will find a bug in Capsicum? As unlikely > as it seems that someone would be able to pull off a MITM attack, > posses a tar or gzip 0day, and also posses a Capsicum 0day, there is > -- like Murphy's law -- that old saying* "Any bug that can be > exploited will be." > > *I definitely just made that up, but I do firmly believe it to be true. > >> What do you mean by a freeze attack? I'm not familiar with this term >> and I didn't find this post, the PRs, or a quick Google search >> illuminating. > > Sorry. A freeze attack is similar to a replay attack. In a replay > attack an attacker would feed the system an older, exploitable version > of the software being updated so that they could break in. A freeze > attack is when an attacker feeds the system the same version of the > software being updated so that critical updates are not installed. > While portsnap and freebsd-update do check to ensure that what's being > updated is no older than what's currently on the system they do not > check to ensure that what's being updated is not the same version as > what's currently installed. > > -David > A paper I found useful back when I first started digging into portsnap and freebsd-update is titled "Package Management Security" and can be found at ftp://ftp.cs.arizona.edu/reports/2008/TR08-02.pdf. It reviews common attacks against package management systems, analyzes both APT and YUM, and points out a number of flaws in them. Many of the attacks discussed also apply to the design of our ports tree management and binary update systems. A very good read for anyone interested in that sort of thing. Baptiste, this conversation made me think of your work on pkgng (I love it, by the way!), so I thought I'd cc you as well. I don't know how knowledgeable you are about common attack vectors against package management systems so I thought maybe this paper would be of some interest to you. I realize I cut off the first email, so if you're curious and didn't see my initial message you can find it here: http://www.mail-archive.com/freebsd-security@freebsd.org/msg04777.html Regards, David Noel ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: MITM attacks against portsnap and freebsd-update
> I'm not convinced that a rototil of the protocol and all the associated > storage duplication is worth the effort. As far as portsnap is concerned I'm not convinced that ANY amount of effort is worth it. That is why I was hoping to start a conversation on the possibility of phasing it out. > It's better in my mind to commit one of the patches to sandbox gzip > with Capsicum... Portsnap also passes un-verified files to tar, so that would need to be patched too. > ...which will protect from everything except filling the > disk by denying gunzip the ability to do anything but write to the file > opened by the script. That will protect all gzip users. I agree that what you're proposing is probably the simplest solution, but I'm not convinced that it would guarantee system security. Nothing against Robert Watson, but sandboxes are always being broken out of. There's a history of vulnerabilities in the jail subsystem, isn't it likely that someone some day will find a bug in Capsicum? As unlikely as it seems that someone would be able to pull off a MITM attack, posses a tar or gzip 0day, and also posses a Capsicum 0day, there is -- like Murphy's law -- that old saying* "Any bug that can be exploited will be." *I definitely just made that up, but I do firmly believe it to be true. > What do you mean by a freeze attack? I'm not familiar with this term > and I didn't find this post, the PRs, or a quick Google search > illuminating. Sorry. A freeze attack is similar to a replay attack. In a replay attack an attacker would feed the system an older, exploitable version of the software being updated so that they could break in. A freeze attack is when an attacker feeds the system the same version of the software being updated so that critical updates are not installed. While portsnap and freebsd-update do check to ensure that what's being updated is no older than what's currently on the system they do not check to ensure that what's being updated is not the same version as what's currently installed. -David ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: A different proposal
On Thu, Apr 10, 2014 at 10:56 AM, Paul Hoffman wrote: > Quite right. It is reasonable to assume that, given what we now know about > the memory allocation scheme in OpenSSL, that other bugs exist and will > only be found by exploits. Thus, it is reasonable to assume that there will > be future emergencies like Heartbleed related to bugs in OpenSSL. > I'm guessing you read a popular post by Theo de Raadt that's been going around. Sorry, but OpenBSD's bastardized memory allocation scheme would not have solved this; OpenSSL's malloc implementation was not to blame here. Amateurish failure to check the sanity of user-supplied input was to blame. Idiotic, error-prone protocol specifications, written by non-programmers, were to blame. OpenSSL's allocator, in this instance, worked fine -- even if it isn't the optimal choice for all operating systems. If your reliance on OpenSSL bugs being fixed requires a fix at a rate > faster than what the FreeBSD community provides, then you should not rely > on the FreeBSD community. Or just make sure that all of your running services link to the OpenSSL library built from ports. While i'm not exactly thrilled with the prospect of waiting a significant amount of time for a vulnerability in the base distribution to be officially patched, relying on the base system for something like that is a bit like taking a tank to the racetrack. > Install OpenSSL on your mission-critical systems from OpenSSL source, not > from FreeBSD ports or packages. This is a poor idea from a maintenance standpoint. Firstly, the ports system was updated fairly quickly, but aside from that, updating an existing port yourself to download and install the next version is usually a trivial task. And you get package management for free. ari ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: A different proposal
On Thu, Apr 10, 2014 at 10:56 AM, Paul Hoffman wrote: > If your reliance on OpenSSL bugs being fixed requires a fix at a rate faster > than what the FreeBSD community provides, then you should not rely on the > FreeBSD community. Install OpenSSL on your mission-critical systems from > OpenSSL source, not from FreeBSD ports or packages. I really don't think one needs to go this far. The workaround provided in the original OpenSSL advisory, recompiling with -DOPENSSL_NO_HEARTBEATS, was directly applicable to FreeBSD. For anyone unsure exactly where to effect that option, it was discussed on this very list. Also posted on this list was a working patch containing the actual fix, on Monday afternoon. So yes, if you want a fully tested, reviewed and supported fix, you had to wait, but anyone in desperate need of an immediate fix had options that didn't involve ditching FreeBSD's OpenSSL. -nd. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: MITM attacks against portsnap and freebsd-update
[Trimming the list to -security plus Colin in hopes of reducing the number of partial conversations. Sending to four lists and an alias is a list etiquette violation.] [Also dropping the discussion of replacing portsnap since that is a mostly unrelated discussion.] On Thu, Apr 10, 2014 at 12:03:45PM -0500, David Noel wrote: > Problem Summary > > 1. Both portsnap and freebsd-update extract fetched data prior to its > SHA256 verification. The extraction libraries used have a long history > of bugs so it's reasonable to assume there might be more. Both > freebsd-update and portsnap are run as root. Using a vulnerability in > the decompression libraries an attacker who was MITM-capable could > compromise any FreeBSD system running portsnap or freebsd-update. > 2. The portsnap mirroring script (pmirror.sh) lacks of any sort of > mechanism to verify the data prior to processing and mirroring it. > Without this, mirrors are open to compromise via methods similar to > those found in the client-side scripts (decompression library > exploitation). It also means an attacker could feed a mirror a corrupt > archive, opening users of that mirror to compromise. These seem like serious issues and a verify-first design would have been better. That said, I'm not convinced that a rototil of the protocol and all the associated storage duplication is worth the effort. It's better in my mind to commit one of the patches to sandbox gzip with Capsicum which will protect from everything except filling the disk by denying gunzip the ability to do anything but write to the file opened by the script. That will protect all gzip users. > 3. Both portsnap and freebsd-update are vulnerable to freeze attacks. What do you mean by a freeze attack? I'm not familiar with this term and I didn't find this post, the PRs, or a quick Google search illuminating. -- Brooks pgpx9sqWDt_0g.pgp Description: PGP signature
Missing binary package security updates?
Hi, I recently started using the new fancy pkgng binary packages on some machines that I maintain. I thought I could save a lot of time as I would not need to keep compiling ports manually any more. Unfortunately it seems that it was not such a good idea: # date Thu Apr 10 21:27:22 EEST 2014 # pkg audit openssl-1.0.1_9 is vulnerable: OpenSSL -- Multiple vulnerabilities - private data exposure CVE: CVE-2014-0076 CVE: CVE-2014-0160 WWW: http://portaudit.FreeBSD.org/5631ae98-be9e-11e3-b5e3-c80aa9043978.html 1 problem(s) in the installed packages found. # pkg upgrade Updating repository catalogue Nothing to do # This is on FreeBSD 8/i386. I think I have noticed binary package updates only about once a week. Is my observation correct? Why such an infrequent update cycle? If there is some real reason to build package updates so rarely, would it be possible to hasten the cycle whenever serious issues like CVE-2014-0160 are found? Right now pkgng binary packages are not really suitable for production use because of lacking essential security updates. (There should be a loud and clear warning about this in the Handbook if it stays this way?) Best Regards, -- Janne Snabb sn...@epipe.com ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
MITM attacks against portsnap and freebsd-update
I found a few bugs in portsnap and freebsd-update that I'd like to bring to the community's attention and hopefully recruit people to help fix. I mentioned them to Colin (their author) a few years ago and he agreed that they're issues that need to be addressed, but in the time since neither he nor I have been able to get around to fixing them. I'm hoping that someone reading this is able and willing to pitch in. I've also taken this to secteam@, but no one there's made any progress on them in the past 6 months so I figured it was time to approach the broader community. Surely there's a benevolent sh-savvy hacker out there who has time to take these on. They're pretty simple fixes -- the functionality that's needed exists in the scripts already, it just needs to be reused in a few key places. I also think it would be an appropriate time to discuss retiring portsnap. Problem Summary 1. Both portsnap and freebsd-update extract fetched data prior to its SHA256 verification. The extraction libraries used have a long history of bugs so it's reasonable to assume there might be more. Both freebsd-update and portsnap are run as root. Using a vulnerability in the decompression libraries an attacker who was MITM-capable could compromise any FreeBSD system running portsnap or freebsd-update. 2. The portsnap mirroring script (pmirror.sh) lacks of any sort of mechanism to verify the data prior to processing and mirroring it. Without this, mirrors are open to compromise via methods similar to those found in the client-side scripts (decompression library exploitation). It also means an attacker could feed a mirror a corrupt archive, opening users of that mirror to compromise. 3. Both portsnap and freebsd-update are vulnerable to freeze attacks. 4. The addition of subversion in base makes portsnap redundant. Solution Summary 1. A re-working of the snapshot hashing and hash verification process. 2. The addition of hashing and hash verification code to pmirror.sh. 3. The server-side inclusion of date-stamps, and strict client-side enforcement of expiration policies. 4. Retire portsnap. Details The functions of concern in portsnap.sh are fetch_snapshot(), fetch_update(), and fetch_snapshot_verify(). The lines of concern in pmirror.sh are 99-103, 121-125, 138-149, and 153-157 (using revision 257073). The functions of concern in freebsd-update.sh are fetch_metadata(), fetch_files_premerge(), and fetch_files(). Retiring Portsnap With the inclusion of svnlite in 10 I think the valid question comes up as to whether we really need the portsnap system or whether it could be safely retired. Obviously if the conclusion of that discussion is that we don't need it then these bug fixes would be unnecessary. The reason I see for it to be retired is that subversion allows us to easily and securely check out the ports tree. It's a one-line command: `svn co https://...`. Keeping it up-to-date it is another one-liner: `cd /usr/ports; svn update`. With the inclusion of svnlite in base, the portsnap code and servers acting as mirrors become redundant and seem like a waste of resources. PR's I've avoided filing PR's to give myself, Colin, or secteam@ the chance to fix these bugs first. Since none of us have had the time free to do so and because I'm now sharing these bugs publicly with the list I figure it would be an appropriate time to file PR's for them. MITM attacks against freebsd-update: http://www.freebsd.org/cgi/query-pr.cgi?pr=188429 MITM attacks against portsnap: http://www.freebsd.org/cgi/query-pr.cgi?pr=188428 Freeze attacks against freebsd-update: http://www.freebsd.org/cgi/query-pr.cgi?pr=188434 Freeze attacks against portsnap: http://www.freebsd.org/cgi/query-pr.cgi?pr=188430 MITM attacks against portsnap mirrors (pmirror.sh): http://www.freebsd.org/cgi/query-pr.cgi?pr=188432 Retiring portsnap: http://www.freebsd.org/cgi/query-pr.cgi?pr=188433 David Noel ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: Proposal
On Thu, Apr 10, 2014 at 01:20:08PM +0200, Dag-Erling Sm??rgrav wrote: > Throwing more manpower at the job won't make a difference; in fact, it > might slow things down due to the need to communicate and coordinate. You mean 9 women can't make a baby in 1 month?!! On Wed, Apr 09, 2014 at 03:44:53PM -0400, Nathan Dorfman wrote: > While I'm out here drawing fire, I might as well also ask if I'm crazy > to think that it might be a good idea for the base system OpenSSL (and > other third party imports) to just disable any and all non-essential > functionality that can be disabled at compile time? Non-essential > meaning everything not required for the base system to function -- > there's always the ports version if anyone needs more. I see the potential benefit but I think I'm opposed to this idea in general. I don't like having partially-crippled software packages in the base system because it ends up being a lot of work to deal with them. Whether you choose to install port/package over top of the base system version or put it in /usr/local you end up with a number of potential issues. I base this on negative experiences that I've had with sendmail, DNS, and kerberos in the past, to name a few. Just my opinion, YMMV obviously. --Jeff ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
A different proposal
On Apr 9, 2014, at 3:46 PM, Pawel Biernacki wrote: > Since such situations had happened in the past and are still > happening, something should be done about them. Quite right. It is reasonable to assume that, given what we now know about the memory allocation scheme in OpenSSL, that other bugs exist and will only be found by exploits. Thus, it is reasonable to assume that there will be future emergencies like Heartbleed related to bugs in OpenSSL. If your reliance on OpenSSL bugs being fixed requires a fix at a rate faster than what the FreeBSD community provides, then you should not rely on the FreeBSD community. Install OpenSSL on your mission-critical systems from OpenSSL source, not from FreeBSD ports or packages. The OpenSSL source will always be updated before the FreeBSD community fixes are released. --Paul Hoffman (who will continue to rely on the FreeBSD community for OpenSSL, and is in fact terribly grateful for the volunteers who did this work as quickly as they did) ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: http://heartbleed.com/
On 10.4.2014, at 15.48, Ed Maste wrote: > On 10 April 2014 06:33, Kimmo Paasiala wrote: >> >> Going back to this original report of the vulnerability. Has it been >> established with certainty that the attacker would first need MITM >> capability to exploit the vulnerability? I'm asking this because MITM >> capability is not something that just any attacker can do. Also if this is >> true then it can be argued that the severity of this vulnerabilty has be >> greatly exaggerated. > > No, the attack does not rely on MITM. The vulnerability is available > to anyone who can establish a connection. Yes of course when you now read the description of the problem at http://heartbleed.com/ it’s completely clear that the attack can be done by anyone. Thanks. -Kimmo signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Heartbleed, a few naive questions
Dne 10.4.2014 12:00, Ronald F. Guilmette napsal(a): Rather, I was asking, albeit indirectly, whether a program or library, such as OpenSSL, which is primarily a security-forcused tool, and upon which a significant fraction of online humanity depends for its security, is deserving of a "belt and suspenders" sytle of defensive programming. [..] (And by the way, it would not be a terribly difficult thing to add to any C compiler a new option that, when used during compilation of select "mission critical" secirity software, would have the effect of generating code for each function that completely zeros at least the statically-sized part of the new stack frame upon entry to the function, or conversely would generate code which would zero the current frame just before function exit. Such an option might be useful when compiling critical security code, such as the OpenSSL library, and if it had been available and used in conjunction with allocation of the problematic buffer on the stack, as I suggested, I believe that those steps, taken together would have eliminated even the possibility of leakage of server-specific secrets. You can have all those safety nets in the code, functions, compilers, but there will be a day, when some creative person will do some creative "optimization" in name of speed, efficiency, whatever. The compiler is forcing zeroing of buffer on allocation in case of size_of buffer is known on compile time? Let it be size_of int + size_of last_tcp_fragment, yeah, we got them. Following thread comes on my mind all the time reading your message http://www.mail-archive.com/misc@openbsd.org/msg128161.html (I don't know which platforms are refered as slow, but it would be funny if we are talking about architecture of which last machine standing was just moved in museum between the computing and paleolitic departments.) -- Ondra ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: http://heartbleed.com/
On 10 April 2014 06:33, Kimmo Paasiala wrote: > > Going back to this original report of the vulnerability. Has it been > established with certainty that the attacker would first need MITM capability > to exploit the vulnerability? I'm asking this because MITM capability is not > something that just any attacker can do. Also if this is true then it can be > argued that the severity of this vulnerabilty has be greatly exaggerated. No, the attack does not rely on MITM. The vulnerability is available to anyone who can establish a connection. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: Heartbleed, a few naive questions
In message <867g6x5u2r@nine.des.no>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= wrote: >"Ronald F. Guilmette" writes: >> Xin Li writes: >> > For this bug, doing calloc() makes no difference. >> I would very much like to know how you reached that conclusion. > >It's very simple. The explpoit relies on reading past the end of the >allocated buffer. You're right, of course, and I missed that. My apologies. My other points still stand however, the most important of which is that the protocol definition itself seems to be asking for trouble, and that this bug was/is the almost inevitable outgrowth of an entirely poorly considered bit of the SSL protocol specification. Hummm... In fact, now that I look at the code some more I'm not even sure if my suggestion for using calloc() in place of malloc() throughout OpenSSL was even entirely off the mark... although the exact _place_ where that suggestion might have been most profitably applied is *not* within the dtls1_process_heartbeat() function itself, but rather is wherever the original receive buffer was allocated, i.e. the buffer that is pointed to by s->s3->rrec.data upon entry to the dtls1_process_heartbeat() function. I have not searched the code to find the place where this original packet receive buffer is allocated, however regardless of whereever this allocation takes place I think that it is safe to say that if such buffers were always allocated to the maximum possible size needed (1+2+65536+16) _and_ if they were always obtained via calls to calloc() or its functional equivalent, then there would never have been such a thing as the Heartbleed bug and this conversation would not now be taking place. Does anyone happen to have a copy of the complete original (unpatched) source code lying around? I have a sudden urge to look and see where exactly the buffer corresponding to s->s3->rrec.data is allocated, with an eye to trying to understand why on earth it was ever made shorter than 1+2+65536+16 bytes long. (Well, actually, it appears that these buffers could all have reasonably be allocated to the rather smaller fixed size of 2^14+16 if the OpenSSL authors had actually followed the RFC. See below.) Regards, rfg P.S. Public reports regarding this bug assert that an attacker can gulp down up to 64KB long chunks of one's private data at a time. I have no reason at present to disbelieve those assertions, however if those assertions are true, then that would seem to suggest that in addition to creating a rather awful bug, the implementors of OpenSSL may have also failed to perform range checking on the payload_length values provided within received HeartbeatRequest packets... range checking that is apparently *MANDITORY* in order to simply meet the requirements of the relevant RFC (6520): "The total length of a HeartbeatMessage MUST NOT exceed 2^14 or max_fragment_length when negotiated as defined in [RFC6066]." ... "If the payload_length of a received HeartbeatMessage is too large, the received HeartbeatMessage MUST be discarded silently. If the OpenSSL authors had simply bothered to implement the requirements of RFC6520, then it would appear that the worst case data leakage would have been on the order of 16KB(-3) per gulp... still quite an awful bug, but not quite as bad as the one currently making headlines. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-14:06.openssl
10/04/2014 12:58 - Cyrus Lopez wrote: > > > >> > >> SSH is not affected. > >> > > > > SSH is indeed not affected, but I guess you should still consider the > > secret sshd key on your otherwise affected server as burnt, as it might > > have been in the memory too while an attacker was inspecting it via > > heartbleed. Better recreate the secret ssh key and all other secret keys on > > your server as well. But, again, the OpenSSH protocol/software per se are > > not affected. > > > This is incorrect. The heartbleed exploit would have only returned portions of > memory that were under the control of OpenSSL, not general memory used by > other > processes on the system. > > > > Thanks for the update. I wasn't aware of that. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: http://heartbleed.com/
On 8.4.2014, at 17.05, Dirk Engling wrote: > On 08.04.14 15:45, Mike Tancsa wrote: > >>I am trying to understand the implications of this bug in the >> context of a vulnerable client, connecting to a server that does not >> have this extension. e.g. a client app linked against 1.xx thats >> vulnerable talking to a server that is running something from RELENG_8 >> in the base (0.9.8.x). Is the server still at risk ? Will the client >> still bleed information ? > > If the adversary is in control of the network and can MITM the > connection, then yes. The client leaks random chunks of up to 64k > memory, and that is for each heartbeat request the server sends. > > erdgeist > Going back to this original report of the vulnerability. Has it been established with certainty that the attacker would first need MITM capability to exploit the vulnerability? I’m asking this because MITM capability is not something that just any attacker can do. Also if this is true then it can be argued that the severity of this vulnerabilty has be greatly exaggerated. -Kimmo signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Proposal
Pawel Biernacki writes: > Dag-Erling Smørgrav writes: > > The freebsd-update build is not a normal make buildworld or make > > release, it's much more complicated than that. > So you're telling me that nothing can be done about it? I'm telling you that you're arguing out of ignorance. Publishing an advisory takes time because there are many steps involved. Wishing that all those tasks only take ten minutes each and can be performed in parallel won't make it so. > And I don't understand why all of those things need to be > single-threaded, I've told you, everything needs to be done in a specific order. You can't mail out the advisory before it's published on the web because it contains links to itself. You can't push the advisory to the web site before it's signed. You can't sign it until it's complete. You can't complete it until you've committed the patches, because it contains information about the commits. You can't commit until after the freebsd-update builds have completed and the binary patches have propagated to all the mirrors, because you want the source and binary patches to go out simultaneously. And so on and so forth. Throwing more manpower at the job won't make a difference; in fact, it might slow things down due to the need to communicate and coordinate. Read your Fred Brooks. > since you even mention asking someone from clusteradm@ to help: Yes, I mentioned getting someone from clusteradm@ to run the web update script manually instead of waiting 10 minutes for the next scheduled update. Trust me, that's not a major sticking point in the process. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: Proposal
On 10 April 2014 08:09, Dag-Erling Smørgrav wrote: > Pawel Biernacki writes: >> If you want to make an excuse that a build took a long time - it's >> really a poor one. If the build cluster is too slow then project need >> to acquire a new one. > > The freebsd-update build is not a normal make buildworld or make > release, it's much more complicated than that. > So you're telling me that nothing can be done about it? >> Many of us had very hard time during last 48 hours. I know that when >> you fill responsible for something you want to do as much as you can, >> but you need to sleep, eat, etc.. If the whole process is to >> overwhelming for one person maybe it's time to think about extending >> the SO team or reorganising the process of preparing patched releases? >> If there is a need of hands, manpower or so why not ask the community >> to help? > > Did you read the part where I said this is mostly single-threaded? > Yes, but you also wrote: > The best you can hope for is to have someone relieve > you while you eat and sleep. And I don't understand why all of those things need to be single-threaded, since you even mention asking someone from clusteradm@ to help: > Once the builds were ready to go, he moved into a phase where everything > had to happen more or less simultaneously: commit the patches, finalize > the advisory (which contains revision numbers and timestamps), sign it, > then commit the advisory and the patch to the doc tree, update the > relevant portions of the web site, wait for them to propagate (or grab a > passing member of clusteradm@ and have them push it through manually), > and finally mail out the advisory. -- One of God's own prototypes. A high-powered mutant of some kind never even considered for mass production. Too weird to live, and too rare to die. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: Heartbleed, a few naive questions
"Ronald F. Guilmette" writes: > Xin Li writes: > > For this bug, doing calloc() makes no difference. > I would very much like to know how you reached that conclusion. It's very simple. The explpoit relies on reading past the end of the allocated buffer. Clearing the allocated buffer would not have made any difference. The problem is the size of the buffer, not its contents. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: Proposal
Joe Holden writes: > IME issues like this need to be patched first, tested later [...] If we'd done that and screwed up, you'd be on the barricades demanding our heads. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-14:06.openssl
>> >> SSH is not affected. >> > > SSH is indeed not affected, but I guess you should still consider the secret > sshd key on your otherwise affected server as burnt, as it might have been in > the memory too while an attacker was inspecting it via heartbleed. Better > recreate the secret ssh key and all other secret keys on your server as well. > But, again, the OpenSSH protocol/software per se are not affected. This is incorrect. The heartbleed exploit would have only returned portions of memory that were under the control of OpenSSL, not general memory used by other processes on the system. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-14:06.openssl
> > SSH is not affected. > SSH is indeed not affected, but I guess you should still consider the secret sshd key on your otherwise affected server as burnt, as it might have been in the memory too while an attacker was inspecting it via heartbleed. Better recreate the secret ssh key and all other secret keys on your server as well. But, again, the OpenSSH protocol/software per se are not affected. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: Heartbleed, a few naive questions
In message <53463a2e.90...@delphij.net>,
Xin Li wrote:
>On 4/9/14, 10:28 PM, Ronald F. Guilmette wrote:
>> 1) Why does OpenSSL even contain a function called
>> "OPENSSL_malloc"? Does anyone other than me think that it might
>> perhaps have been a better choice to provide only a function called
>> "OPENSSL_calloc"?
>
>For this bug, doing calloc() makes no difference.
I would very much like to know how you reached that conclusion. I may
be wrong in this instance... I have been, on more than one occasion in
my lifetime... but I do disagree with your conclusion in this instance.
The bug is described in some great detail here:
http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html
What I believe to the the text of the buggy code in question appears to be
available here:
http://code.woboq.org/crypto/openssl/ssl/d1_both.c.html
For the information being leaked to an attacker by this bug, where exactly
do _you_ believe it is coming from, if not out of a buffer which has been
allocated (out of recycled and non-cleared memory) by the call to
OPENSSL_malloc?
>Is doing calloc() a
>good practice in general? Sometimes it is, sometimes it merely slows
>things down.
I agree entirely. If data leakage is occurring within the program that
I use to crop my vacation pictures, the world will not be terribly the
worse for it. but that was not the question I was asking. Rather, I
was asking, albeit indirectly, whether a program or library, such as
OpenSSL, which is primarily a security-forcused tool, and upon which
a significant fraction of online humanity depends for its security,
is deserving of a "belt and suspenders" sytle of defensive programming.
>> 2) Not that this would actually have eliminated the bug, but...
>>
>> Was there some compelling reason why space for the "buffer" at
>> issue was allocated via a call to "OPENSSL_malloc", rather than,
>> say, simply being declared as a function-local "auto"
>> char[1+2+65536+padding] ?
>
>Automatic arrays are introduced with C99.
I am sorry that I failed to be clear. My question has/has nothing to do
what what you are calling "automatic arrays" and what I would prefer to
call "dynamically sized arrays". If you look at the actual code you will
see that "padding" is not really a variable quantity. Rather it appears
to have a fixed value (16). So the real question I had intended to pose
was actually: "Why wasn't space for the buffer obtained by a simple local
variable declaration of the following general form?"
enum { padding = 16 };
auto char buffer[1+2+65536+padding];
or more simply:
auto char buffer[1+2+65536+16];
>By the way, how do you benefit from allocating from stack than from
>heap for relatively large chunk of memory?
Doing so is unambiguously more efficient, and provides an absolute assurance
that the memory will be fully and properly reclaimed at the instant the
containing function exits, however just with respect to the security issues
alone, I must admit that this might possibly not make any difference at all,
specifically in relation to memory leakage of those secrets which belong
*to the server itself*. However depending on how (or whether) memory
which is allocated to hold execution stacks is pre-zeroed (before being
given to a process or a thread) and depending on whether each SSL session
gets its own separate thread (and thus also its own private execution stack)
allocating buffers out of the stack, rather than out of the (common) process-
wide heap might at least prevent leakage of secrets belonging to one client
to a different client.
(And by the way, it would not be a terribly difficult thing to add to any
C compiler a new option that, when used during compilation of select
"mission critical" secirity software, would have the effect of generating
code for each function that completely zeros at least the statically-sized
part of the new stack frame upon entry to the function, or conversely
would generate code which would zero the current frame just before
function exit. Such an option might be useful when compiling critical
security code, such as the OpenSSL library, and if it had been available
and used in conjunction with allocation of the problematic buffer on the
stack, as I suggested, I believe that those steps, taken together would
have eliminated even the possibility of leakage of server-specific secrets.
Such an approach might seem extreme to some, but would it have been worse
that the current mess the net finds itself in?)
>> 3) Not that this would actually have eliminated the bug, but...
>>
>> After making some effort to do so, I have been unable to find any
>> information online which would serve to document the initial state
>> of the blocks of memory allocated by calls to pthread_create().
>> Would any of you happen to know if said blocks are or, conversely,
>> are not cleared to zeros prior to execution of the created
>> thread(s)?
>
>I don't think I unders
Re: Proposal
On Wed, 9 Apr 2014 19:00:52 +0100, Pawel Biernacki wrote: > On 9 April 2014 17:08, Joe User wrote: > > On 09.04.2014 17:29, Pawel Biernacki wrote: > >> [snip] > >> We need more transparency here. > >> > > > > Please read this and other related threads and you'll understand that > > the FreeBSD-SecTeam had no real chance to react earlier than they did. > > http://seclists.org/oss-sec/2014/q2/22 > > > > In fact, they were realy fast, thanks therefor. Personally, I'm well impressed by the speed (and care) with which this happened, in the by now very well explained course of events. Special thanks to Xin for all the single-threaded work and Dag-Erling for the explanations, though I'm sure there were other willing hands on deck. > Interesting lecture, thank you. But if FreeBSD SO wasn't on the > mentioned list it's an argument for payable position because that can > help developing more efficient social network in the future ;-). That's no argument for a paid SO at all, but seeing a few people banging on how throwing money at such problems could or should help, I'd like to offer a counter argument - off-topic as this whole aspect surely is. In a largely voluntary project such as FreeBSD, or for that matter any number of community volunteer efforts, the introduction of paid staff can - unless handled with extreme sensitivity - be a kiss of death. As soon as there's someone/s whose paid job it is to perform such roles, many of the other, voluntary members of a team such as Security are more likely to tend to sit back and expect or allow the employee to 'do his or her job'. However well-meaning, that's a natural tendency that can often dissipate the collaborative energies of enthusiastic volunteers; I've seen this occur in many once-voluntary organisations over 40 years. As far as I can determine, the Foundation already supports the SO and other senior developers in other useful ways; conference accomodation and travel, access to infrastructure, etc, and provides grants to people for specific projects, including ongoing ones like Release Engineering; this is entirely appropriate and serves to consolidate voluntary energy, not to compete with it. My 2 Yen - I know, not worth much these days - Ian ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: Proposal
Pawel Biernacki writes: > If you want to make an excuse that a build took a long time - it's > really a poor one. If the build cluster is too slow then project need > to acquire a new one. The freebsd-update build is not a normal make buildworld or make release, it's much more complicated than that. > Many of us had very hard time during last 48 hours. I know that when > you fill responsible for something you want to do as much as you can, > but you need to sleep, eat, etc.. If the whole process is to > overwhelming for one person maybe it's time to think about extending > the SO team or reorganising the process of preparing patched releases? > If there is a need of hands, manpower or so why not ask the community > to help? Did you read the part where I said this is mostly single-threaded? DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
