Hi OpenSSL Developers, I think we've just discovered a bug, either in our understanding of how to properly code various structures, or in the OpenSSL encoding i2d and d2i routines for constructs that contain implicitly tagged, but optional General names.
The attached files contain a simple example showing the problem. In the first
struct, the initial optional element is a GENERAL_NAME, but somehow, after i2d
and then d2i, it gets filled with the content of the subsequent UTF8STRING (or,
rather, that content is re-interpretted into a GENERAL_NAME type).
In the second struct, the initial optional element is another UTF8STRING, and
the decoding shows that no such incorrect content placement (we've also tried
several other types, and it appears that GENERAL_NAME is the only type that
causes this behaviour.
GDB shows this quite clearly:
Breakpoint 1, main () at opensslbug.c:110
110 return 0;
(gdb) p *r
$1 = {badstring = 0x0, mystr = 0x8056458}
This is the original structure. badstring is empty...
(gdb) p *r2
$2 = {badstring = 0x8056870, mystr = 0x0}
but after d2i, badstring is now populated...
With a struct that doesn't contain a General Name, we don't see this behaviour:
Original Struct:
(gdb) p *r3
$3 = {badstring = 0x0, mystr = 0x80568a8}
new struct after i2d -> d2i:
(gdb) p *r4
$4 = {badstring = 0x0, mystr = 0x8056960}
(gdb)
If anyone can shed any light on this, it would be appreciated.
---
Patrick Patterson
Chief PKI Architect
Carillon Information Security Inc.
http://www.carillon.ca
opensslbug.c
Description: Binary data
opensslbug.h
Description: Binary data
