| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
At least SMIME_text() relies on this. Pushing an error on the stack trips
PKCS7 regress in py-cryptography, so indicate nothing was written instead
of throwing an error.
Reported by Alex Gaynor a while back
ok jsing
|
|
|
|
|
|
|
| |
i removed the arithmetics -> arithmetic changes, as i felt they
were not clearly correct
ok tb
|
|
|
|
| |
OK tb@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
jsing@ worries that cycle prevention might increase risk because
software that is not checking return values (and indeed, not checking
is likely common in practice) might silently behave incorrectly
with cycle prevention whereas without, it will likely either crash
right away through infinite recursion or at least hang in an infinite
loop when trying to use the cyclic chain, in both cases making it
likely that the bug will be found and fixed.
Besides, tb@ points out that BIO_set_next(3) ought to behave as
similarly as possible to BIO_push(3), but adding cycle prevention
to BIO_set_next(3) would be even less convincing because that
function does not provide a return value, encouraging users to
expect that it will always succeed. While a safe idiom for checking
the success of BIO_set_next(3) could easily be designed, let's be
realistic: application software would be highly unlikely to pick up
such an idiom.
|
|
|
|
|
|
| |
and reports failure if a call would result in a cycle.
The algorithm used was originally suggested by jsing@.
Feedback and OK tb@.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and next_bio fields of all BIO objects in all affected chains, no
matter what the arguments are.
In particular, if the second argument (the one to be appended) is
not at the beginning of its chain, properly detach the beginning
of its chain before appending.
We have weak indications that this bug might affect real-world code.
For example, in FreeRDP, file libfreerdp/crypto/tls.c, function
bio_rdp_tls_ctrl(), case BIO_C_SET_SSL, BIO_push(3) is definitely
called with a second argument that is *not* at the beginning of its
chain. Admittedly, that code is hard to fathom, but it does appear
to result in a bogus prev_bio pointer without this patch.
The practical impact of this bug in this and other software remains
unknown; the consequences might possibly escalate up to use-after-free
issues if BIO_pop(3) is afterwards called on corrupted BIO objects.
OK tb@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
invariants of the prev_bio and next_bio fields of all BIO objects
in all involved chains, no matter which arguments this function is
called with.
Both real-world uses of this function (in libssl and freerdp) have
been audited to make sure this makes nothing worse. We believe libssl
behaves correctly before and after the patch (mostly because the second
argument is NULL there), and we believe the code in freerdp behaves
incorrectly before and after the patch, leaving a prev_bio pointer in
place that is becoming bogus, only in a different object before and
after the patch. But after the patch, that bogus pointer is due to a
separate bug in BIO_push(3), which we are planning to fix afterwards.
Joint work with and OK tb@.
|
|
|
|
|
|
|
|
|
| |
As schwarze points out, you can pop any BIO in a chain, not just the first
one (bonus points for a great name for this API).
The internal doubly linked was used to fix up the BIO chain bio was part
of when you BIO_pop() a bio that wasn't in the first position, which is
explicitly allowed in our documentation and implied by OpenSSL's.
|
|
|
|
|
|
|
|
|
|
| |
For various historical reasons, there are a number of cases where our
BIO_read() and BIO_write() return slightly different values to what
OpenSSL 3.x does (of course OpenSSL 1.0 differs from OpenSSL 1.1 which
differs from OpenSSL 3.x). Mostly align these - some further work will be
needed.
Issue raised by tb@ who also wrote some test code.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While BIO chains are doubly linked lists, nothing has ever made use of this
fact internally. Even libssl has failed to maintain prev_bio properly in
two places for a long time. When BIO was made opaque, the opportunity to
fix that was missed. Instead, BIO_set_next() now allows breaking the lists
from outside the library, which freerdp has long done.
Problem found by schwarze while trying to document BIO_set_next().
schwarze likes the idea
ok jsing
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Passing an indent value of 67 results in DUMP_WIDTH_LESS_IDENT returning a
value of zero, which is promptly used for division. Likewise, passing a
value larger than 67 results in a negative value being returned.
Prevent this by limiting indent to 64 (which matches OpenSSL's current
behaviour), as well as ensuring that dump_width is > 0.
Should fix oss-fuzz #52464 and #52467.
ok miod@ tb@
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Various projects use bio_info_cb and BIO_info_cb interchangeably, for
example mupdf and freerdp. This is because this was changed in OpenSSL
commit fce78bd4 (2017), triggered by new warnings in gcc 8.
https://github.com/openssl/openssl/pull/4493
This results in some scary compiler warnings and useless patches in ports.
Nobody seems to be using the old bio_info_cb() version.
ok jsing
|
|
|
|
|
|
|
|
| |
If the bgets() callback returns <= 0, we currently rely on the user
provided callback to set readbytes, which isn't ideal. This also
matches what's done in BIO_read() and BIO_write().
ok jsing
|
|
|
|
|
|
|
| |
This script is not used at all and files are edited by hand instead.
Thus remove misleading comments incl. the obsolete script/config.
Feedback OK jsing tb
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, a read/write memory BIO pulls up the data via memmove() on each
read. This becomes very expensive when a lot of small reads are performed,
especially if there is a reasonable amount of data stored in the memory
BIO.
Instead, store a read offset into the buffer and only perform a memmove()
to pull up the data on a write, if we have read more than 4096 bytes. This
way we only perform memmove() when the space saving will potentially be of
benefit, while avoiding frequent memmove() in the case of small interleaved
reads and writes.
Should address oss-fuzz #19881.
ok inoguchi@ tb@
|
|
|
|
|
|
|
|
|
| |
In order to fix and improve the memory BIO, we need to be able to track
more than just a single BUF_MEM *. Provide a struct bio_mem (which
currently only contains a BUF_MEM *) and rework the internals to use this
struct.
ok inoguchi@ tb@
|
|
|
|
|
|
|
|
| |
This is a first pass that uses sensible and consistent names for variables.
Call the BIO 'bio' (instead of 'a', 'b', 'bp', or 'h'), drop a bunch of
unnecessary casts, simplify some logic and add additional error checking.
With input from and ok tb@
|
|
|
|
|
|
|
|
|
|
| |
This provides support for new-style BIO callbacks in
BIO_{read,write,gets,puts}() and a helper function to
work out whether it should call the new or the old
style callback. It also adds a few typedefs and minor
code cleanup as well as the BIO_{get,set}_callback_ex()
from jsing, ok tb
|
|
|
|
|
|
|
| |
Move BIO, BIO_METHOD and BIO_F_BUFFER_CTX to bio_local.h and provide
BIO typedef in ossl_typ.h.
ok inoguchi jsing
|
|
|
|
|
|
|
| |
Pointed out by schwarze. How something with this name ever made
its way into a public header will remain a mystery.
ok inoguchi jsing
|
|
|
|
|
| |
This marks the start of major surgery in libcrypto. Do not attempt to
build the tree for a while (~50 commits).
|
|
|
|
|
|
| |
that will need it in the upcoming bump.
discussed with jsing
|
|
|
|
|
|
| |
Needed by freerdp.
ok inoguchi jsing
|
|
|
|
|
|
| |
This will be needed in libssl and freerdp after the next bump.
ok inoguchi jsing
|
|
|
|
|
|
|
|
|
|
| |
how application software uses the API function BIO_indent(3):
If the caller asks for some output, but not more than some negative
number of bytes, give them zero bytes of output rather than drowning
them in nearly INT_MAX bytes.
OK tb@
|
|
|
|
| |
ok jsing
|
|
|
|
|
|
| |
no longer needed.
ok jsing
|
|
|
|
| |
ok beck jsing
|
|
|
|
|
|
|
|
|
|
|
| |
is pure comedy gold, and now documented as such, sadly this bit of pure
Muppet genius can't really in good consience stay in the tree as is.
Change BIO_dump to always return the number of bytes printed on success
and to stop printing and return -1 on failure if a writing function
fails.
ok tb@, jsing@
|
|
|
|
|
|
|
| |
Instead of blindly skipping 14 characters, we can use the return
value of snprintf() to determine how much we should skip.
From Martin Vahlensieck with minor tweaks by me
|
|
|
|
|
| |
code was inspecting the pointer (which is, sadly, undefined on error, because
the current specification of asprintf is crazy sloppy)
|
|
|
|
|
|
|
|
|
| |
Some bread/bwrite functions implement this themselves, while others do not.
This makes it consistent across all BIO implementations.
Addresses an issue that Guido Vranken found with his fuzzer.
ok tb@
|
|
|
|
|
|
|
|
| |
BIO_meth_get_callback_ctrl, BIO_meth_get_create, BIO_meth_get_ctrl,
BIO_meth_get_destroy, BIO_meth_get_gets, BIO_meth_get_puts,
BIO_meth_get_read, and BIO_meth_get_write.
ok jsing
|
|
|
|
|
| |
tested in a bulk build by sthen
ok bcook, jsing
|
|
|
|
|
|
|
|
| |
BIO_new_accept(). The one for BIO_new_mem_buf() is a bit ugly
since it needs to cast away the newly added const qualifier,
as in OpenSSL commit 8ab31975bac.
ok jsing
|
|
|
|
|
|
| |
BIO_s_datagram().
ok jsing
|
|
|
|
|
|
| |
functions.
ok beck, jsing
|
|
|
|
|
|
|
|
|
| |
This adds OPENSSL_init_crypto and OPENSSL_init_ssl, as well
thread safety modifications for the existing LibreSSL init
functions. The initialization routines are called automatically
by the normal entry points into the library, as in newer OpenSSL
ok jsing@, nits by tb@ and deraadt@
|
|
|
|
| |
ok jsing
|
| |
|
| |
|
|
|
|
| |
with & ok jsing
|
|
|
|
| |
ok jsing
|
|
|
|
| |
ok jsing
|
|
|
|
| |
ok jsing
|
|
|
|
| |
Based on BoringSSL.
|
|
|
|
| |
ok jsing
|
|
|
|
| |
ok jsing
|
|
|
|
|
|
| |
and BIO_meth_set_{puts,read,write}().
ok jsing
|
|
|
|
|
|
| |
passed to BIO_get_accept_socket(). This is part of the API and it
fixes "openssl ocsp -port 12345" in server mode.
from markus@; OK jsing@ beck@
|