A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=libressl-v3.2.1 2020-07-23T17:15:35+00:00 2020-07-23T17:15:35+00:00 schwarze 2020-07-23T17:15:35+00:00 urn:sha1:bc9c51cf66fc92815074622c1c64a0e8bd9d5796 use-after-free and double-free issues in calling programs. The bug was introduced in SSLeay-0.6.0 released on June 21, 1996 and has been present since OpenBSD 2.4. I found the bug while documenting the function. The bug could bite in two ways that looked quite different from the perspective of the calling code: * If a stack was passed in that already contained some X509_INFO objects and an error occurred, all the objects passed in would be freed, but without removing the freed pointers from the stack, so the calling code would probable continue to access the freed pointers and eventually free them a second time. * If the input BIO contained at least two valid PEM objects followed by at least one PEM object causing an error, at least one freed pointer would be put onto the stack, even though the function would return NULL rather than the stack. But the calling code would still have a pointer to the stack, so it would be likely to access the new bogus pointers sooner or later. Fix all this by remembering the size of the input stack on entry and cutting it back to exactly that size when exiting due to an error, but no further. While here, do some related cleanup: * Garbage collect the automatic variables "error" and "i" which were only used at one single place each. * Use NULL rather than 0 for pointers. I like bugfixes that make the code four lines shorter, reduce the number of variables by one, reduce the number of brace-blocks by one, reduce the number if if-statements by one, and reduce the number of else-clauses by one. Tweaks and OK tb@. 2020-07-16T01:50:25+00:00 beck 2020-07-16T01:50:25+00:00 urn:sha1:d4354bce356f56b21d16015ca9fb3aeed6bf2c42 2020-07-15T03:49:59+00:00 beck 2020-07-15T03:49:59+00:00 urn:sha1:ae88adfabd15a5b8ba717c6f480a0184d9ecece5 2020-07-15T03:44:42+00:00 beck 2020-07-15T03:44:42+00:00 urn:sha1:63d4dabdf271a3dddcd6df97631bb9c8c227a897 2020-07-15T03:13:25+00:00 beck 2020-07-15T03:13:25+00:00 urn:sha1:55fd08e9f0222e9194a52692ff91d778c1bd8d7b bettertls.com, and a verification suite to try each certificate in the same manner as the web based tests do using X509_verify. This includes the list of "known" failures today in our validaion code so we can move forward without moving back. 2020-07-14T18:33:34+00:00 jsing 2020-07-14T18:33:34+00:00 urn:sha1:54e6b184aac6eaf631e6f6ae7d8089bd18cf3ade 2020-07-14T18:33:00+00:00 jsing 2020-07-14T18:33:00+00:00 urn:sha1:62fffcc6da72e47aafab1fcd6e774db68a45533b A number of these tests are known to fail due to bugs/incorrect verification implementation. 2020-07-14T18:29:19+00:00 jsing 2020-07-14T18:29:19+00:00 urn:sha1:58a8e9343cbb766a48028b93f90d03b844f52c87 ok beck@ tb@ 2020-07-14T18:27:28+00:00 jsing 2020-07-14T18:27:28+00:00 urn:sha1:0b35dc8b41a7d66a38844b2e7511381a2056d824 This provides a script that generates a variety of certificate chains and assembles them into bundles containing various permutations, which can be used to test our X.509 verification. A Go program is included to verify each of these bundles. ok beck@ tb@ 2020-06-04T21:21:03+00:00 schwarze 2020-06-04T21:21:03+00:00 urn:sha1:be3505dc014b9b7022575b6fe4f9c78c2080281c failure rather than silently constructing a broken X509_ATTRIBUTE object that might cause NULL pointer accesses later on. This matters because X509_ATTRIBUTE_create() is used by documented API functions like PKCS7_add_attribute(3) and the NID comes straight from the user. This fixes a bug found while working on documentation. OK tb@ and "thanks" bluhm@