| Summary: | SSL 3.0 [RFC6101] SSLv3 POODLE vulnerability CVE-2014-3566 | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Sona Sarmadi <sona.sarmadi> |
| Component: | connectivity | Assignee: | Sona <sona.sarmadi> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | High | CC: | bluelightning, meta.mr.watcher, meta.watcher, richard.purdie, sgw, sjolley.yp.pm |
| Version: | unspecified | ||
| Target Milestone: | 1.5.4 | ||
| Hardware: | Other | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | Don't know | |
|
Description
Sona Sarmadi
2014-10-15 06:45:41 UTC
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? 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 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 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 Fix merged for 1.7 and 1.6 branches. 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? 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. 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 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. Paul, can you look at wget? I will as well 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. |