refactoring is always risky. Kinda wonder what an exploit scenario would look like though; it has to be a malicious server, the user has to be intentionally trying to reach it via SOCKS, and they must have some kind of ongoing service relationship for the server to have fingerprinted the client well enough to push an effective payload.
I wonder if the upcoming bounds checked c rfc features from Apple in clang would be helpful at the very least as a defensive measure. but they also seem to be moving fairly slowly :(
There is still something fundamentally wrong that a single person should be (read: feel) accountable for something like this. People make mistakes and there is nothing to feel bad about.
If a detached signature is actually a PGP message, gpgme_op_verify() returns
the rather perplexing GPG_ERR_NO_ERROR, and then gpgme_op_verify_result()
builds an empty list.
Explicitly check for no...
# Summary:
The SOCKS5 state machine can be manipulated by a remote attacker to overflow heap memory if four conditions are met:
1. The request is made via socks5h.
2. The state machine's...
Troed Sångberg
in reply to daniel:// stenberg:// • • •"Typical server latency is likely "slow" enough to trigger this bug"
Nitpicking - but if it's the typical case it sounds a bit strange to refer to it as slow? :)
Erik Moeller
in reply to daniel:// stenberg:// • • •Eduard Toloza
in reply to daniel:// stenberg:// • • •Terence Eden
in reply to daniel:// stenberg:// • • •You are only human. But you're a pretty good human.
Thanks for the clear and detailed write up.
Winfried Angele 🇺🇦🇪🇺
in reply to daniel:// stenberg:// • • •Christian Kündig
in reply to daniel:// stenberg:// • • •daniel:// stenberg://
in reply to Christian Kündig • • •Christian Kündig
in reply to daniel:// stenberg:// • • •Howard Chu @ Symas
in reply to daniel:// stenberg:// • • •daniel:// stenberg://
in reply to Howard Chu @ Symas • • •Leonard Ritter
in reply to daniel:// stenberg:// • • •Stefan Eissing
in reply to daniel:// stenberg:// • • •Claudia
in reply to daniel:// stenberg:// • • •systemd-jaded
in reply to daniel:// stenberg:// • • •Max
in reply to daniel:// stenberg:// • • •sabik
in reply to daniel:// stenberg:// • • •Jef
in reply to daniel:// stenberg:// • • •anders.infosec 💬
in reply to daniel:// stenberg:// • • •Great write up!
There is still something fundamentally wrong that a single person should be (read: feel) accountable for something like this. People make mistakes and there is nothing to feel bad about.
Richard Hughes
in reply to daniel:// stenberg:// • • •speaking from personal experience, it's okay to make mistakes: github.com/fwupd/fwupd/commit/… :)
Well done on the handling -- and please don't take any of the criticism personally; you're doing a great job.
Validate that gpgme_op_verify_result() returned at least one signature · fwupd/fwupd@21f2d12
GitHubdaniel:// stenberg://
in reply to daniel:// stenberg:// • • •curl disclosed on HackerOne: CVE-2023-38545: socks5 heap buffer...
HackerOneBenBE
in reply to daniel:// stenberg:// • • •I don't always overflow buffers,
but when I do, I curl up on it …
eatscrayon
in reply to daniel:// stenberg:// • • •TJ
in reply to daniel:// stenberg:// • • •“In hindsight, shipping a heap overflow in code installed in over twenty billion instances is not an experience I would recommend.”
Wise words indeed
daniel:// stenberg://
in reply to TJ • • •