6843 2014-10-15 06:45:41 +0000 SSL 3.0 [RFC6101] SSLv3 POODLE vulnerability CVE-2014-3566 2014-12-08 15:47:53 +0000 1 1 7 Build System, Metadata & Runtime OE-Core connectivity unspecified Other Multiple RESOLVED FIXED High major 1.5.4 1 sona.sarmadi sona.sarmadi bluelightning meta.mr.watcher meta.watcher richard.purdie sgw sjolley.yp.pm --- --- Don't know oldest_to_newest 46333 0 sona.sarmadi 2014-10-15 06:45:41 +0000 Yesterday The Register published this: http://www.theregister.co.uk/2014/10/14/nasty_ssl_30_vulnerability_to_drop_tomorrow/ and today following was published: https://www.openssl.org/~bodo/ssl-poodle.pdf http://googleonlinesecurity.blogspot.de/2014/10/this-poodle-bites-exploiting-ssl-30.html The advice is: Disable SSLv3. 46340 1 sona.sarmadi 2014-10-15 10:21:33 +0000 Additional info: http://askubuntu.com/questions/537196/how-do-i-patch-workaround-sslv3-poodle-vulnerability-cve-2014-3566 http://thenextweb.com/google/2014/10/15/web-encryption-vulnerability-opens-encrypted-data-hackers/ A patch to mitigate the issue is avaiable here: http://marc.info/?l=openssl-dev&m=141333049205629&w=2 The question is if we can disable SSLv3 and use TLS or is it dependency for other packages? 46406 2 sona.sarmadi 2014-10-17 09:53:31 +0000 Adding Bryan Evenson comments on this issues: I did a few quick searches of recipe names and descriptions on the meta-openembedded and poky (which includes oe-core) layers for SSL and TLS relation. The searches I used from the poky directory were: find meta* -name "*ssl*.bb" find meta* -name "*tls*.bb" grep -nrE '(ssl|SSL|tls|TLS)' meta* | grep -vE '(DSSSL|dsssl|[Ll]ossless)' | grep '\.bb:' Then ignoring packages that expressly disable SSL, here's what I found for other packages to evaluate: python-pyopenssl socat curl libsoup packagegroup-toolset-native packagegroup-core-basic packagegroup-core-lsb ltp mailx libarchive iputils msmtp webkit-gtk packagegroup-self-hosted eglibc glib-networking x11vnc bind telepathy-idle openssh valgrind tcf-agent python-native python rpm neon nostromo cherokee apache2 ajenti net-snmp claws-mail sylpheed libimobiledevice loudmouth hostap-daemon gateone libtorrent krb5 networkmanager nodejs4 nodejs libc-client python-twisted python-m2crypto links links-x11 openldap gsoap mbuffer cryptsetup iksemel strongswan ca-certificates libetpan cyrus-sasl vsftpd accel-ppp openvpn znc azy midori oscam tvheadend Almost all the packages require openssl or gnutls, so patching openssl and gnutls may be sufficient for most of these packages. I'm still working with the dylan branch. If any new packages have been added since then I may have missed them. I'm not sure how dropbear does its encryption, so that may be one to look at also. Regards, Bryan Evenson 46407 3 sona.sarmadi 2014-10-17 09:54:58 +0000 Adding some comments from email thread: > Presumably the list of affected packages is: > - gnutls > - openssl > - nss There's a openssl 1.0.1j out now (fixing FOUR (!) CVEs, including "disabling SSLv3 didn't work"...). I think considering the situation we'd take the upgrade for dizzy, even though we've frozen. Anyone volunteering to take lead of upgrading dizzy to 1.0.1j and backporting the relevant patches to the previous releases? (eg daisy is on 1.0.1g). Ross On 15 October 2014 16:31, Burton, Ross <ross.burton@intel.com> wrote: > There's a openssl 1.0.1j out now (fixing FOUR (!) CVEs, including > "disabling SSLv3 didn't work"...). I think considering the situation > we'd take the upgrade for dizzy, even though we've frozen. Anyone > volunteering to take lead of upgrading dizzy to 1.0.1j and backporting > the relevant patches to the previous releases? (eg daisy is on > 1.0.1g). For anyone else interested, I've currently got 1.0.1j patches for dizzy in testing. There's been debate over whether we backport the fixes to daisy's 1.0.1g, or upgrade as the number of fixes is growing... Ross ================================== I think the upgrade is the way to go. We are likely to break 1.0.1g someday during backporting of security fixes. -- Otavio Salvador 46440 4 sona.sarmadi 2014-10-20 07:53:52 +0000 For the vulnerability in the GnuTLS see: http://www.gnutls.org/security.html#GNUTLS-SA-2014-4 and Nikos' writeup here: http://nmav.gnutls.org/2014/10/what-about-poodle.html 46544 5 sjolley.yp.pm 2014-10-23 15:06:51 +0000 Fix merged for 1.7 and 1.6 branches. 46896 6 sona.sarmadi 2014-11-10 08:54:10 +0000 Fixed in dora: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=dora&id=faaf75d24faa9862407cd478317101d155bb3129 Investigating further if we need to do anything else about this issue? i.e. fixes in other related recipes? 46901 7 sona.sarmadi 2014-11-10 14:40:22 +0000 I think we need to apply this patch to disable SSL 3.0 in python 2.7 and 3.x: http://bugs.python.org/issue22638 I have looked at NSS and cURL packages, I don't think these packages are affected by this vulnerability. 47197 8 sona.sarmadi 2014-11-26 07:37:24 +0000 I have crated a patch which disables SSLv3 in python if we define "OPENSSL_NO_SSL3". The patch is taken from: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768611 Should we patch wget also to disable SSLv3? https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1276641.html 47292 9 sona.sarmadi 2014-12-02 15:30:39 +0000 There are two patches: 1) http://bugs.python.org/issue22638 (patch name: issue22638.diff, http://bugs.python.org/file36926/issue22638.diff) This patch disables SSLv3 by default for Python. But I couldn't apply this patch. It seems this is for newer python version. 2) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768611#22 (python2.7-nossl3.patch) Building without SSLv3 support when openssl is built without any support for SSLv3 I have applied #2, I am running some tests. When I am done I will send the patch to OE-core. 47294 10 sgw 2014-12-02 16:13:40 +0000 Paul, can you look at wget? I will as well 47314 11 sona.sarmadi 2014-12-03 07:42:00 +0000 Created separate bugs for wget (Bug 7016), pyhton (Bug 7015) and curl (Bug 7017). 47425 12 bluelightning 2014-12-08 15:47:53 +0000 I've just created bug 7041 to cover webkit-gtk. As far as I can tell, of the OE-Core recipes out of those listed above, there are no more that really need fixes that don't have corresponding bugs. Therefore I'm marking this bug as resolved.