Re: [Sks-devel] Re: zero-length MPIs (was: Re: mpi error with check-trustdb in 1.4.2 - resolved)
On Wed, Aug 24, 2005 at 03:07:17PM +0200, Klaus Singvogel wrote:
> I noticed that these messages are coming from
> mpi/mpicoder.c:mpi_read() and had a closer look at it. :-)
>
> The second if check, for "goto overflow;" seems a bit doubtful (maybe
> a copy&paste without to much thinking whats coming next ? :-) As
> there are no mandatory reads from the iobuf coming, only optional
> reads, I changed the code to "if (++nread > nmax)" and the problem
> was gone (see attached patch).
I think this is very close, but not perfect. You must also protect
against accidentally reading too many bytes, as then you can't parse
the rest of the stream.
Try this patch.
David
Index: mpicoder.c
===
--- mpicoder.c (revision 3878)
+++ mpicoder.c (working copy)
@@ -80,16 +80,20 @@
mpi_limb_t a;
MPI val = MPI_NULL;
+if (nread == nmax)
+goto overflow;
if( (c = iobuf_get(inp)) == -1 )
goto leave;
-if (++nread >= nmax)
+nread++;
+nbits = c << 8;
+
+if (nread == nmax)
goto overflow;
-nbits = c << 8;
if( (c = iobuf_get(inp)) == -1 )
goto leave;
-if (++nread >= nmax)
-goto overflow;
+nread++;
nbits |= c;
+
if( nbits > MAX_EXTERN_MPI_BITS ) {
log_error("mpi too large for this implementation (%u bits)\n", nbits);
goto leave;
@@ -112,7 +116,7 @@
for( ; j > 0; j-- ) {
a = 0;
for(; i < BYTES_PER_MPI_LIMB; i++ ) {
-if (nread >= nmax) {
+if (nread == nmax) {
#ifdef M_DEBUG
mpi_debug_free (val);
#else
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [Sks-devel] Re: zero-length MPIs (was: Re: mpi error with check-trustdb in 1.4.2 - resolved)
Hi.
Jason Harris wrote:
> On Thu, Aug 11, 2005 at 09:54:59PM +0200, Peter Palfrader wrote:
> > On Thu, 11 Aug 2005, Jason Harris wrote:
>
> > > Fetching them from keyserver.kjsl.com is now possible with gnupg-1.4.2.
> > > To patch pks, add this to the middle of decode_mpi() (in pgputil.c):
> > >
> > > /* skip packets with 0-length MPIs for GPG's benefit (gnupg-1.4.2) */
> > > if (mpi->nbits == 0) {
> > > return (0);
> > > }
> >
> > can we do that in SKS too? please!
>
> Try the patch below. 0x1A9537E7 is another offending key, and all eight
> work now:
>
[...]
I don't see those files in my copy of gnupg-1.4.2. where your patch
applies. Therefore I looked myself closer at the code, as this problem
araises unter "gpg --trustdb" at some of our users.
I noticed that these messages are coming from
mpi/mpicoder.c:mpi_read() and had a closer look at it. :-)
The second if check, for "goto overflow;" seems a bit doubtful (maybe
a copy&paste without to much thinking whats coming next ? :-) As
there are no mandatory reads from the iobuf coming, only optional
reads, I changed the code to "if (++nread > nmax)" and the problem
was gone (see attached patch).
Please confirm me, that my thinking is correct here.
Thanks in advance.
Regards,
Klaus.
--
Klaus Singvogel
SUSE LINUX Products GmbH
Maxfeldstr. 5 E-Mail: [EMAIL PROTECTED]
90409 Nuernberg Phone: +49 (0) 911 740530
Germany GnuPG-Key-ID: 1024R/5068792D 1994-06-27
--- gnupg-1.4.2/mpi/mpicoder.c.orig 2005-05-31 08:30:05.0 +0200
+++ gnupg-1.4.2/mpi/mpicoder.c 2005-08-24 14:51:07.0 +0200
@@ -87,7 +87,7 @@
nbits = c << 8;
if( (c = iobuf_get(inp)) == -1 )
goto leave;
-if (++nread >= nmax)
+if (++nread > nmax)
goto overflow;
nbits |= c;
if( nbits > MAX_EXTERN_MPI_BITS ) {
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [Sks-devel] Re: zero-length MPIs (was: Re: mpi error with check-trustdb in 1.4.2 - resolved)
On Thu, Aug 11, 2005 at 09:54:59PM +0200, Peter Palfrader wrote:
> On Thu, 11 Aug 2005, Jason Harris wrote:
> > Fetching them from keyserver.kjsl.com is now possible with gnupg-1.4.2.
> > To patch pks, add this to the middle of decode_mpi() (in pgputil.c):
> >
> > /* skip packets with 0-length MPIs for GPG's benefit (gnupg-1.4.2) */
> > if (mpi->nbits == 0) {
> > return (0);
> > }
>
> can we do that in SKS too? please!
Try the patch below. 0x1A9537E7 is another offending key, and all eight
work now:
%gpg --recv 0xA0B3E88B 0xFC05DA69 0x0FCF6738 0xCC78C893 0x98FDE37C 0x74C9DE33
0x57023F00 0x1A9537E7
...
gpg: Total number processed: 8
gpg: unchanged: 8
===
RCS file: parsePGP.ml,v
retrieving revision 1.1
diff -u -r1.1 parsePGP.ml
--- parsePGP.ml 2005/08/12 00:03:16 1.1
+++ parsePGP.ml 2005/08/12 00:03:54
@@ -23,6 +23,7 @@
open Printf
exception Overlong_mpi
+exception Zerolen_mpi
exception Partial_body_length of int
()
@@ -109,6 +110,7 @@
try
let byte2 = cin#read_byte in
let length = (byte1 lsl 8) + byte2 in
+if length <= 0 then raise Zerolen_mpi;
let data = cin#read_string
((length + 7)/8)
in
--
Jason Harris | NIC: JH329, PGP: This _is_ PGP-signed, isn't it?
[EMAIL PROTECTED] _|_ web: http://keyserver.kjsl.com/~jharris/
Got photons? (TM), (C) 2004
pgptUfKrOLys6.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
zero-length MPIs (was: Re: mpi error with check-trustdb in 1.4.2 - resolved)
On Thu, Aug 11, 2005 at 12:02:17PM -0400, Jason Harris wrote:
> On Wed, Aug 10, 2005 at 10:30:09PM -0500, John Clizbe wrote:
> > Tracked down the two offending keys and deleted them with 1.4.1. They both
> > failed to import from a keyserver with 1.4.2 with the same mpi error, so I'm
> > marking it off to key cruft.
Here are some more offending keys:
0xA0B3E88B
0xFC05DA69
0x0FCF6738
0xCC78C893
0x98FDE37C
0x74C9DE33
0x57023F00 - corrupt subkey
Fetching them from keyserver.kjsl.com is now possible with gnupg-1.4.2.
To patch pks, add this to the middle of decode_mpi() (in pgputil.c):
/* skip packets with 0-length MPIs for GPG's benefit (gnupg-1.4.2) */
if (mpi->nbits == 0) {
return (0);
}
--
Jason Harris | NIC: JH329, PGP: This _is_ PGP-signed, isn't it?
[EMAIL PROTECTED] _|_ web: http://keyserver.kjsl.com/~jharris/
Got photons? (TM), (C) 2004
pgpXeuUVhq6vB.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
