Summary: | <net-misc/dropbear-2012.55: weakness in embedded version of mp_prime_next_prime() opens a security risk | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | Mark Karpeles <mark> |
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | embedded, jer, kfm |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | B4 [glsa] | ||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 405607 | ||
Bug Blocks: |
Description
Mark Karpeles
2010-07-15 15:12:17 UTC
Adding security@gentoo.org as CC (recommanded by bonsaikitten on irc) Got reply from upstream regarding this issue: Thanks for the notice - I'll try to get a Dropbear fix in the next few days. I'll have to think about the best way to test existing keys in the wild. dropbear-0.53 is in the tree now Thank you. Could you take a more detailed look at the upstream's ChangeLog? - Attempt to build against system libtomcrypt/libtommath if available. This can be disabled with ./configure --enable-bundled-libtom I didn't see any mention of that in the new ebuild, so either we have an automagic dependency, or we're missing an important opportunity to disable this bundled library. The problem seems to be that libtommath has no maintainer and the version in tree is vulnerable (bug #328383). What's your advice then? Okay, so dropbear-0.53.1 is in tree, but it doesn't DEPEND on libtommath, so it is likely to use the vulnerable bundled version. Maintainers, please resolve this issue or at least comment on it. dropbear appears to bundle and use libtomcrypt 1.16 and libtommath 0.40. Setting econf --disable-bundled-libtom does not appear to make it use the system version. But setting LTC and LTM does appear to work: Index: dropbear-2012.55.ebuild =================================================================== RCS file: /var/cvsroot/gentoo-x86/net-misc/dropbear/dropbear-2012.55.ebuild,v retrieving revision 1.1 diff -u -B -r1.1 dropbear-2012.55.ebuild --- dropbear-2012.55.ebuild 24 Feb 2012 18:24:24 -0000 1.1 +++ dropbear-2012.55.ebuild 25 Feb 2012 18:07:56 -0000 @@ -53,7 +53,7 @@ src_compile() { set_options - emake ${makeopts} PROGRAMS="${progs}" + emake LTC=/usr/lib/libtomcrypt.a LTM=/usr/lib/libtommath.a ${makeopts} PROGRAMS="${progs}" } src_install() { (In reply to comment #6) > dropbear appears to bundle and use libtomcrypt 1.16 and libtommath 0.40. > > Setting econf --disable-bundled-libtom does not appear to make it use the > system version. But setting LTC and LTM does appear to work: Needs more than that, since it would still use the bundled headers. If dropbear is using the bundled libtommath, we shouldn't be vulnerable any more. Upstream changelog [1] shows the issue fixed in 0.53: Fix a prime generation bug in bundled libtommath. This is unlikely to have generated any bad keys in the wild. See https://bugzilla.redhat.com/show_bug.cgi?id=615088 http://bugs.gentoo.org/show_bug.cgi?id=328383 http://bugs.gentoo.org/show_bug.cgi?id=328409 [1] https://matt.ucc.asn.au/dropbear/CHANGES Added to existing request. @maintainers: cleanup, please. (In reply to Chris Reffett from comment #9) > Added to existing request. @maintainers: cleanup, please. Looks to me like we should remove the following versions (cutting and pasting from eshowkw) | | u | | a a p s | n | | l m h i m m p s p | u s | r | p d a p a 6 i p c 3 a x | s l | e | h 6 r p 6 8 p p 6 9 s r 8 | e o | p | a 4 m a 4 k s c 4 0 h c 6 | d t | o --------------+---------------------------+-----+------- 0.52 | + + + + + + ~ + + + + + + | # 0 | gentoo 0.52-r1 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | # | gentoo 0.53.1 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | # | gentoo 2011.54 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | # | gentoo and we should keep [I]2012.55 | + + + + + + ~ + + + + + + | o | gentoo 2013.56 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | # | gentoo 2013.57 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | # | gentoo 2013.58 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | o | gentoo I can do that in a week if there are no objections --- mostly this is vapier's package so I don't want to step on toes. This issue was resolved and addressed in GLSA 201309-20 at http://security.gentoo.org/glsa/glsa-201309-20.xml by GLSA coordinator Chris Reffett (creffett). |