Bug#381204: GnuPG security hole in memory allocation

2006-08-04 Thread Werner Koch
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

2006-08-03 Thread Martin Pitt
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

2006-08-02 Thread Brian M. Carlson
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