Failure on 10.0? Re: FreeBSD Security Advisory FreeBSD-SA-15:06.openssl [REVISED]
# sudo freebsd-update fetch Looking up update.FreeBSD.org mirrors... 5 mirrors found. Fetching metadata signature for 10.0-RELEASE from update6.freebsd.org... done. Fetching metadata index... done. Inspecting system... done. Preparing to download files... done. The following files will be added as part of updating to 10.0-RELEASE-p18: /usr/src/contrib/tzdata/zone1970.tab /usr/src/crypto/openssl/crypto/constant_time_locl.h /usr/src/crypto/openssl/crypto/constant_time_test.c /usr/src/crypto/openssl/doc/apps/c_rehash.pod /usr/src/crypto/openssl/doc/crypto/CMS_add1_signer.pod /usr/src/crypto/openssl/doc/ssl/SSL_CTX_set_tlsext_ticket_key_cb.pod /usr/src/crypto/openssl/ssl/heartbeat_test.c /usr/src/crypto/openssl/ssl/ssl_utst.c /usr/src/crypto/openssl/util/mkbuildinf.pl /usr/src/secure/lib/libcrypto/man/CMS_add1_signer.3 /usr/src/secure/lib/libssl/man/SSL_CTX_set_tlsext_ticket_key_cb.3 /usr/src/secure/usr.bin/openssl/man/c_rehash.1 WARNING: FreeBSD 10.0-RELEASE-p18 HAS PASSED ITS END-OF-LIFE DATE. Any security issues discovered after Sat Feb 28 19:00:00 EST 2015 will not have been corrected. # sudo freebsd-update install Installing updates...install: ///usr/src/contrib/tzdata/zone1970.tab: No such file or directory install: ///usr/src/crypto/openssl/crypto/constant_time_locl.h: No such file or directory install: ///usr/src/crypto/openssl/crypto/constant_time_test.c: No such file or directory install: ///usr/src/crypto/openssl/doc/apps/c_rehash.pod: No such file or directory install: ///usr/src/crypto/openssl/doc/crypto/CMS_add1_signer.pod: No such file or directory install: ///usr/src/crypto/openssl/doc/ssl/SSL_CTX_set_tlsext_ticket_key_cb.pod: No such file or directory install: ///usr/src/crypto/openssl/ssl/heartbeat_test.c: No such file or directory install: ///usr/src/crypto/openssl/ssl/ssl_utst.c: No such file or directory install: ///usr/src/crypto/openssl/util/mkbuildinf.pl: No such file or directory install: ///usr/src/secure/lib/libcrypto/man/CMS_add1_signer.3: No such file or directory install: ///usr/src/secure/lib/libssl/man/SSL_CTX_set_tlsext_ticket_key_cb.3: No such file or directory install: ///usr/src/secure/usr.bin/openssl/man/c_rehash.1: No such file or directory done. It doesn't look like OpenSSL got updated, and it looks like a bunch of the attempted updates failed. Was this advisory tested on 10.0? --Paul Hoffman signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Security SSH
On Jan 13, 2015, at 9:31 AM, Zoran Kolic zko...@sbb.rs wrote: Can you point to that for the rest of us? I'd rather not wade in openbsd-misc The link original poster presented is the correct one. Openbsd tend to set some default values, which one might like or not. I would disable root login at first. Misc seems rough at moment. I found it very helpfull if I need help, just have to follow rules. Be patient, give as much info as possible, don't push... Do your homework... If I really have to say what I think: ssh is great tool. In the FreeeBSD space, enabling root login for SSH by default is problematic on both sides of the sword. - If it enabled by default, and the root password is purposely easy to remember (because it is a single-user system), it's easy to get owned. - If it is disabled by default, you either have to be able to log in once from the console (which you might not have access to if it is a VM), or the one user who was added has to be part of the right group *and* you need to remember the right incantation for su. On balance, I'm happy with the FreeBSD default of PermitRootLogin no even though it has made creating new FreeBSD VMs troublesome for me sometimes. ...and I'm glad we're not discussing the uninformed crypto FUD that started this thread... --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: Security SSH
On Jan 12, 2015, at 8:40 AM, Zoran Kolic zko...@sbb.rs wrote: In fact, you got answer on openbsd misc list. Can you point to that for the rest of us? I'd rather not wade in openbsd-misc --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: Potential security issues with new top level domains?
On Nov 16, 2014, at 6:38 PM, Jamie Landeg-Jones ja...@dyslexicfish.net wrote: Yes, the 'A' returned is invalid in this case, but what's to say this will be the case with all future new TLDs? It will be the case for the first 90 days for all new TLDs that have three or more letters in their names; it will probably not be true for new TLDs with two letters in their name. I realise the spec is being followed correctly, Yes. but it still seems wrong to me that any 'host' related resource types resolve for an address at the top level, and I was wondering what others thought about it? The spec is being followed correctly, and there are many other TLDs that do this: see https://tools.ietf.org/html/rfc7085. Should the FreeBSD resolver ignore / not make such requests? Should instead the functionality be built into unbound/named etc.? Should instead TLD owners be banned from adding such records? (this still could be abused though) No, no, and no. As you say above, the spec is being followed. You can mitigate your misuse of the DNS: https://www.icann.org/en/system/files/files/name-collision-mitigation-01aug14-en.pdf. --Paul Hoffman (a long-time FreeBSDer who co-wrote the above RFC, and also wrote the ICANN report) ___ 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
pkg repositories out of alignment (was: Re: bash velnerability)
Just a note that the pkg repo for 10 seems to be far advanced over that for 9.3. That is, the bash fix appeared in the 10 repo yesterday (or earlier), but it still not in the 9.3 repo. Here's what I'm seeing on a 9.3 box right now: # sudo pkg update Updating FreeBSD repository catalogue... FreeBSD repository is up-to-date. All repositories are up-to-date. # sudo pkg audit bash-4.3.24 is vulnerable: bash -- remote code execution vulnerability CVE: CVE-2014-7169 CVE: CVE-2014-6271 WWW: http://portaudit.FreeBSD.org/71ad81da-4414-11e4-a33e-3c970e169bc2.html 1 problem(s) in the installed packages found. # sudo pkg upgrade bash Updating FreeBSD repository catalogue... FreeBSD repository is up-to-date. All repositories are up-to-date. Checking integrity... done (0 conflicting) Your packages are up to date. I appreciate the speed that folks update the packages; I'm a bit distressed that 9.3 seems to be a second-class citizen for security fixes. (And I totally admit that I could be misreading the situation.) --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: deprecating old ciphers from OpenCrypto...
On Sep 5, 2014, at 3:25 PM, John-Mark Gurney j...@funkthat.com wrote: Skipjack: already removed by OpenBSD and recommend not for use by NIST after 2010, key size is 80 bits Yes, nuke. CAST: key size is 40 to 128 bits CAST 128 is not weak. Having said that, it is also not used much, and has minor (if any) value over AES-128. I can't tell from your message if you are leaving CAST 128 in; if so, you should leave CAST 128 in as well. If CAST 128 is the max in the module, you can either remove all of CAST or leave CAST 128 in, it doesn't matter. --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: Speed and security of /dev/urandom
On Jul 18, 2014, at 11:19 AM, Leif Pedersen bi...@hobbiton.org wrote: The extra readers interrupt the position of the stream, so that it is harder to predict the next value. This only works if one instance of the PRNG is shared by multiple readers, rather than each reader operating in isolation. If there was a non-zero chance that an attacker could predict the next value, your PRNG was already broken. Two of the fundamental properties of a working PRNG is that if an attacker sees any number of outputs from the PRNG, the attacker cannot compute any previous values and the attacker cannot predict any future values. --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: RFC: Proposal: Install a /etc/ssl/cert.pem by default?
On Jul 2, 2014, at 4:45 PM, Xin Li delp...@delphij.net wrote:
Currently, FreeBSD does not install a default /etc/ssl/cert.pem
because we do not maintain one ourselves. We do, however, provide a
port, security/ca_root_nss, which have an option to install a symbolic
link as /etc/ssl/cert.pem - /usr/local/share/certs/ca-root-nss.crt,
which is not the default option.
This become a problem when applications, e.g. fetch(8), have grown the
support of doing certificate validation. I think now it makes sense
to have a default cert.pem installed with the base system.
So my proposal would be:
1. Import a set of trusted root certificates, and install if
MK_OPENSSL is yes, to /usr/share/misc/ca-root-freebsd.pem;
2. In src/etc/Makefile, automatically create a symbolic link if it's
not already present in ${DESTDIR}/etc/ssl;
3. Teach mergemaster(8) and other similar applications to create the
symbolic link on demand;
4. Change the install/deinstall behavior of security/ca_root_nss:
ETCSYMLINK checked: If /etc/ssl/cert.pem exists, back it up on
install then overwrite with new symlink, and restore on deinstall.
ETCSYMLINK unchecked: If /etc/ssl/cert.pem do not pre-exist,
install new a symlink; on deinstall, if
/usr/share/misc/ca-root-freebsd.pem exists, replace the symlink with a
symlink to there, or remove if the file does not exist.
Comments/objections?
It seems like a good plan. As long as people who have a different trust list
than Mozilla can easily implement their own trust plan, it's fine, and this
brings a lot of ease-of-use to the ports, particularly to common ones like wget.
--Paul Hoffman
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: ports requiring OpenSSL not honouring OpenSSL from ports
On May 1, 2014, at 3:03 AM, Uwe Doering gem...@geminix.org wrote: I indeed wondered why this variable hadn't been mentioned so far. Guys, you do have WITH_OPENSSL_PORT=yes in your /etc/make.conf, haven't you? Because otherwise the whole thread might be considered a false alert. The ports system does not link with the ports' OpenSSL of its own accord. Or at least not in a reliable/predictable manner. You have to explicitly tell it what you want. Please consider whether it is appropriate to chide people for not knowing about an *undocumented* feature of make.conf. I'll turn in a pr for it. --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: ports requiring OpenSSL not honouring OpenSSL from ports
On May 1, 2014, at 8:26 AM, Uwe Doering gem...@geminix.org wrote: On 01.05.14 16:33, Paul Hoffman wrote: I'll turn in a pr for it. docs/189199 Good idea. I would think that this should be mentioned at least in pkg-descr of the openssl port, where it gets displayed by portmaster and perhaps other port management tools after each install. ports/189208 ___ 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: ports requiring OpenSSL not honouring OpenSSL from ports
On Apr 27, 2014, at 8:08 AM, Jamie Landeg-Jones ja...@dyslexicfish.net wrote: Basically what I'm asking: Shouldn't a port that uses OpenSSL *always* build against the port if it's installed? Yes, that is a reasonable expectation. I certainly had it in my head when I rebuilt Sendmail+TLS after heartbleed, but I didn't think of checking it. I realise this isn't always possible to test, especially if the port Makefile doesn't have any openSSL configuration options, but I'd like to hear others opinions on the matter. It would be good to add such options to as many ports as possible if it can be done cleanly. Also, note that this is not bashing on OpenSSL: given their new significant funding, I would certainly expect the OpenSSL project to be finding-and-fixing Heartbleed-level bugs repeatedly in the coming years. It is basically impossible to fix such a bug without bad actors being able to determine and exploit some of the fixes in unpatched systems. --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
A different proposal
On Apr 9, 2014, at 3:46 PM, Pawel Biernacki pawel.bierna...@gmail.com 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: A different proposal
On Apr 10, 2014, at 12:34 PM, Nathan Dorfman n...@rtfm.net wrote: On Thu, Apr 10, 2014 at 10:56 AM, Paul Hoffman paul.hoff...@vpnc.org 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: A different proposal
On Apr 10, 2014, at 12:36 PM, ari edelkind edelkind-list-freebsd-secur...@episec.com 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: [PATCH RFC] Disable save-entropy in jails
On Dec 24, 2013, at 12:44 PM, Xin Li delp...@delphij.net wrote: I think we shouldn't save entropy inside jails, as the data is not going to be used by rc script (pjd@126744). If there is no objections, I will commit this changeset on January 1, 2014. Even if it is not used by an rc script, it might be used by some userland program (running as root, of course) that knows about the directory and wants some fresh entropy for its own use. Is there a problem with saving the directory in jails? It certainly isn't taking up much space. --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: [PATCH RFC] Disable save-entropy in jails
On Dec 24, 2013, at 2:53 PM, Xin Li delp...@delphij.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 12/24/13 14:36, Paul Hoffman wrote: On Dec 24, 2013, at 12:44 PM, Xin Li delp...@delphij.net wrote: I think we shouldn't save entropy inside jails, as the data is not going to be used by rc script (pjd@126744). If there is no objections, I will commit this changeset on January 1, 2014. Even if it is not used by an rc script, it might be used by some userland program (running as root, of course) that knows about the directory and wants some fresh entropy for its own use. Why a userland application would want to use these? Would you mind elaborating what kind of use that would be? I don't have a specific application in mind, and certainly not one for a jail. However, I'm not sure what the value in removing a feature for a jail if we don't know if anyone is using that feature. Thus, my question. My understanding is that the saved entropy is used for bootstraping the system only: any applications that wants good random numbers should just use /dev/random because relying on something saved on disk is the worst way for someone who wants more entropy. Quite true. Note, however, that we don't delete the saved entropy after booting and add it just before shutdown: we leave it there for some reason. I'm not sure why a jail is so different of an environment that it should be treated differently than a normal (non-jail) environment. Maybe there is a reason, but I'm not seeing it. Is there a problem with saving the directory in jails? It certainly isn't taking up much space. No, it's not about space. What I am concerned is that it may have wasted entropy: each time (every */11 minute) the system would get 2048 bytes out from /dev/random per jail. This deterministic behavior may trigger reseeds earlier than wanted. I did not understand this. What changes in the system does removing /var/db/entropy cause? (If this is answered in a longer article, a pointer to it would be useful to me (and maybe others).) --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
Question about FreeBSD Security Advisory FreeBSD-SA-13:14.openssh
Greetings again. Why does this announcement only apply to: Affects:FreeBSD 10.0-BETA That might be the only version where aes128-gcm and aes256-gcm are in the defaults, but other versions of FreeBSD allow you to specify cipher lists in /etc/ssh/sshd_config. I would think that you would need to update all systems running OpenSSH 6.2 and 6.3, according to the CVE. FWIW, when I did a freebsd-update on my 9.2-RELEASE system, sshd (6.2) was not updated. --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: Question about FreeBSD Security Advisory FreeBSD-SA-13:14.openssh
On Nov 19, 2013, at 7:54 AM, Darren Pilgrim list_free...@bluerosetech.com wrote: On 11/19/2013 7:44 AM, Paul Hoffman wrote: Greetings again. Why does this announcement only apply to: Affects:FreeBSD 10.0-BETA That might be the only version where aes128-gcm and aes256-gcm are in the defaults, but other versions of FreeBSD allow you to specify cipher lists in /etc/ssh/sshd_config. I would think that you would need to update all systems running OpenSSH 6.2 and 6.3, according to the CVE. FWIW, when I did a freebsd-update on my 9.2-RELEASE system, sshd (6.2) was not updated. The other requirement for being vulnerable is OpenSSH must be compiled with TLS 1.2 support (i.e., linked to OpenSSL v1.0.1 or later). FreeBSD 9.2 only has OpenSSL 0.9.8.y. Very clear explanation, thanks! (I note that this wasn't even hinted at in the CVE...) --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
