of OpenSSL.
Julia Lawall a écrit :
A few years ago, we did some experiments on finding problems in error
handling in OpenSSL using Coccinelle:
Finding Error Handling Bugs in OpenSSL using Coccinelle
http://coccinelle.lip6.fr/papers/edcc10.pdf
It's a bit surprising if none of those tools could
A few years ago, we did some experiments on finding problems in error
handling in OpenSSL using Coccinelle:
Finding Error Handling Bugs in OpenSSL using Coccinelle
Julia Lawall, Ben Laurie, René Rydhof Hansen, Nicolas Palix, Gilles
Muller.
Eighth European Dependable Computing Conference, EDCC
The function BIO_ctrl can return a negative integer in an error case. In
the same file, some calls to similar functions, eg BIO_flush, are checked
as though both negative and zero error values are possible.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
//
The function BIO_ctrl can return a negative integer in an error case. A
few lines below, a call to a similar function, BIO_flush, is checked
as though both negative and zero error values are possible.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
// smpl
The function BIO_write can return a negative integer or zero in an error
case. Thus, testing whether the result is nonzero is not meaningful.
Other nearby code tests whether it is less than or equal to 0, which is the
change made here.
The semantic patch that helps find this problem is as
The function BIO_write can return a negative integer in an error case. The
same is true of i2a_ASN1_INTEGER and i2a_ASN1_OBJECT. The result of
BIO_printf is determined by the result of a call to BIO_write. Thus, in
all of these cases an error should be detected by a less than or equal to
zero
The function EVP_DigestVerifyFinal can return a negative integer in an
error case, so the result should be tested with = 0.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
// smpl
@match@
expression x, E;
position p1,p2,p3;
constant C;
@@
(
break; //
The function EVP_SealInit can return a negative integer in an
error case, so the result should be tested with = 0.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
// smpl
@match@
expression x, E;
position p1,p2,p3;
constant C;
@@
(
break; // parsing
The function EVP_SealInit can return a negative integer in an
error case, so the result should be tested with = 0.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
// smpl
@match@
expression x, E;
position p1,p2,p3;
constant C;
@@
(
break; // parsing
In each case, the value of i might be the result of calling i2b_PVK_bio,
i2b_PublicKey_bio, or i2b_PrivateKey_bio, each of which can return a
negative value in case of an error. Thus the result should be tested with
= 0. On the other hand, it appears that if OPENSSL_NO_RSA or
OPENSSL_NO_DSA is
The function BN_exp can return a negative integer in an error case, so its
result should be checked with = 0 rather than !.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
// smpl
@expression@
expression list args;
@@
- BN_exp(args) == 0
+ BN_exp(args)
The function BIO_write can return a negative integer or zero in an error
case. Thus, it should be tested whether it is less than or equal to zero,
and not simply whether it is equal to zero, to detect errors. Other nearby
calls to BIO_printf, whose return value is determined by a call to
The function OPENSSL_isservice can return -1 in the case of error. This
code appears to be interested in the case where the call succeeds. Thus, I
have converted the test on the result to 0. Alternatively, since
OPENSSL_isservice can only return -1, 0, or 1, the call could be converted
to
The function ENGINE_ctrl sometimes returns 0 to indicate an error and
sometimes returns -1. In each of the cases below, the goal seems to be to
return 1 only in the case of success. Therefore the result of ENGINE_ctrl
should be tested using 0.
The semantic patch that makes this change is as
The function EVP_PKEY_sign can explicitly return -1 or -2 in the case of
error. Therefore, the error checking code should check whether the result
is less than or equal to 0, and not just whether it is equal to zero.
The semantic patch that makes this change is as follows:
The function CMS_get1_ReceiptRequest can explicitly return 0 or -1 in the
case of error. Therefore, the error checking code should check whether the
result is less than or equal to 0, and not just whether it is equal to
zero.
The semantic patch that makes this change is as follows:
The function RAND_bytes returns -1 if it is not supported by the current
RAND method, and 0 for other kinds of errors. Perhaps it is statically
known at these call sites that -1 is not a possible result. But if that is
not the case, then the test on the call should be converted to a = 0
test.
-- Forwarded message --
Date: Sun, 13 Sep 2009 12:09:23 +0200 (CEST)
From: Julia Lawall ju...@diku.dk
Reply-To: openssl-dev@openssl.org
To: openssl-dev@openssl.org, Rene Rydhof Hansen r...@cs.aau.dk,
Gilles Muller - lip6 gilles.mul...@lip6.fr, z...@google.com
Subject: [PATCH
-- Forwarded message --
Date: Sun, 13 Sep 2009 11:29:27 +0200 (CEST)
From: Julia Lawall ju...@diku.dk
Reply-To: openssl-dev@openssl.org
To: openssl-dev@openssl.org, Rene Rydhof Hansen r...@cs.aau.dk,
Gilles Muller - lip6 gilles.mul...@lip6.fr, z...@google.com
Subject: [PATCH
-- Forwarded message --
Date: Sun, 13 Sep 2009 11:14:00 +0200 (CEST)
From: Julia Lawall ju...@diku.dk
Reply-To: openssl-dev@openssl.org
To: openssl-dev@openssl.org, Rene Rydhof Hansen r...@cs.aau.dk
Cc: z...@google.com, Gilles Muller - lip6 gilles.mul...@lip6.fr
Subject: [PATCH
-- Forwarded message --
Date: Sun, 13 Sep 2009 10:49:06 +0200 (CEST)
From: Julia Lawall ju...@diku.dk
Reply-To: openssl-dev@openssl.org
To: openssl-dev@openssl.org, Rene Rydhof Hansen r...@cs.aau.dk,
Gilles Muller - lip6 gilles.mul...@lip6.fr, z...@google.com
Subject: [PATCH
-- Forwarded message --
Date: Sun, 13 Sep 2009 10:32:49 +0200 (CEST)
From: Julia Lawall ju...@diku.dk
Reply-To: openssl-dev@openssl.org
To: openssl-dev@openssl.org, Rene Rydhof Hansen r...@cs.aau.dk,
z...@google.com, Gilles Muller - lip6 gilles.mul...@lip6.fr
Subject: [PATCH
22 matches
Mail list logo
