Bug#381204: GnuPG security hole in memory allocation
On Wed, 2 Aug 2006 21:37, Brian M. Carlson said: I am inclined to say that this is grave, but since gnupg tends to do memory allocation before it drops privileges, you might find that this The allocation problem, which is overflow like malloc(numbercontrolledbyuser+20), can only happen after privs are dropped. It is in the parser of the actual OpenPGP data. So there is no privilege escalation just a normal remote code execution possible. BTW, In general I don't think it is worth to install gpg suid(root); there are too may other bugs in the entire OS which will make it easier to get the password than through a swap file. Salam-Shalom, Werner -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#381204: GnuPG security hole in memory allocation
Hi, I extracted a minimal patch from 1.4.5 for the Sarge security update. This has been assigned CVE-2006-3746. Thanks, Martin -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org In a world without walls and fences, who needs Windows and Gates? --- gnupg-1.4.4/g10/parse-packet.c 2006-06-25 10:58:40.0 + +++ gnupg-1.4.5/g10/parse-packet.c 2006-07-26 10:39:16.0 + @@ -2088,6 +2088,16 @@ parse_comment( IOBUF inp, int pkttype, u { byte *p; +/* Cap comment packet at a reasonable value to avoid an integer + overflow in the malloc below. Comment packets are actually not + anymore define my OpenPGP and we even stopped to use our + private comment packet. */ +if (pktlen65536) + { + log_error (packet(%d) too large\n, pkttype); + iobuf_skip_rest (inp, pktlen, 0); + return G10ERR_INVALID_PACKET; + } packet-pkt.comment = xmalloc(sizeof *packet-pkt.comment + pktlen - 1); packet-pkt.comment-len = pktlen; p = packet-pkt.comment-data; @@ -2340,6 +2351,9 @@ parse_gpg_control( IOBUF inp, int pkttyp if ( sesmark[i] != iobuf_get_noeof(inp) ) goto skipit; } +if (pktlen 4096) + goto skipit; /* Definitely too large. We skip it to avoid an + overflow in the malloc. */ if ( list_mode ) puts (- gpg control packet); signature.asc Description: Digital signature
Bug#381204: GnuPG security hole in memory allocation
Package: gnupg Version: 1.4.3-2 Severity: grave Tags: security GnuPG 1.4.5 corrects some potential security problems in memory allocation. From http://lists.gnupg.org/pipermail/gnupg-announce/2006q3/000229.html : * Fixed 2 more possible memory allocation attacks. They are similar to the problem we fixed with 1.4.4. This bug can easily be be exploted for a DoS; remote code execution is not entirely impossible. I am inclined to say that this is grave, but since gnupg tends to do memory allocation before it drops privileges, you might find that this is critical instead. If you drop the SUID privileges, then it certainly does not exceed grave. I do not have a CVE number for this. -- ($_,$a)=split/\t/,join'',map{unpack'u',$_}DATA;eval$a;print;__DATA__ M961H[EMAIL PROTECTED];!UF%OG-U(#QUF%OG-U0=D:75MUC8VUL=G)U;6LN MFUL+F=Y/@H)2QA8F-D969G:EJ:VQM;F]P7)S='5V=WAYBQN=V]R8FMC 5:75Q96AT9V1YF%L=G-P;6IX9BP) pgp90AKIO6yuV.pgp Description: PGP signature