📅 Original date posted:2019-11-08
📝 Original message:It goes without saying in that all privately known CVE should be handled so professionally but, that is, well done team.
Regards,
LORD HIS EXCELLENCY JAMES HRMH
________________________________
From: bitcoin-dev-bounces at lists.linuxfoundation.org <bitcoin-dev-bounces at lists.linuxfoundation.org> on behalf of Luke Dashjr via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
Sent: Saturday, 9 November 2019 2:07 AM
To: bitcoin-dev at lists.linuxfoundation.org <bitcoin-dev at lists.linuxfoundation.org>
Cc: security at bitcoincore.org <security at bitcoincore.org>
Subject: [bitcoin-dev] CVE-2017-18350 disclosure
CVE-2017-18350 is a buffer overflow vulnerability which allows a malicious
SOCKS proxy server to overwrite the program stack on systems with a signed
`char` type (including common 32-bit and 64-bit x86 PCs).
The vulnerability was introduced in 60a87bce873ce1f76a80b7b8546e83a0cd4e07a5
(SOCKS5 support) and first released in Bitcoin Core v0.7.0rc1 in 2012 Aug 27.
A fix was hidden in d90a00eabed0f3f1acea4834ad489484d0012372 ("Improve and
document SOCKS code") released in v0.15.1, 2017 Nov 6.
To be vulnerable, the node must be configured to use such a malicious proxy in
the first place. Note that using *any* proxy over an insecure network (such
as the Internet) is potentially a vulnerability since the connection could be
intercepted for such a purpose.
Upon a connection request from the node, the malicious proxy would respond
with an acknowledgement of a different target domain name than the one
requested. Normally this acknowledgement is entirely ignored, but if the
length uses the high bit (ie, a length 128-255 inclusive), it will be
interpreted by vulnerable versions as a negative number instead. When the
negative number is passed to the recv() system call to read the domain name,
it is converted back to an unsigned/positive number, but at a much wider size
(typically 32-bit), resulting in an effectively infinite read into and beyond
the 256-byte dummy stack buffer.
To fix this vulnerability, the dummy buffer was changed to an explicitly
unsigned data type, avoiding the conversion to/from a negative number.
Credit goes to practicalswift (https://twitter.com/practicalswift) for
discovering and providing the initial fix for the vulnerability, and Wladimir
J. van der Laan for a disguised version of the fix as well as general cleanup
to the at-risk code.
Timeline:
- 2012-04-01: Vulnerability introduced in PR #1141.
- 2012-05-08: Vulnerability merged to master git repository.
- 2012-08-27: Vulnerability published in v0.7.0rc1.
- 2012-09-17: Vulnerability released in v0.7.0.
...
- 2017-09-21: practicalswift discloses vulnerability to security team.
- 2017-09-23: Wladimir opens PR #11397 to quietly fix vulernability.
- 2017-09-27: Fix merged to master git repository.
- 2017-10-18: Fix merged to 0.15 git repository.
- 2017-11-04: Fix published in v0.15.1rc1.
- 2017-11-09: Fix released in v0.15.1.
...
- 2019-06-22: Vulnerability existence disclosed to bitcoin-dev ML.
- 2019-11-08: Vulnerability details disclosure to bitcoin-dev ML.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191108/aace00bf/attachment-0001.html>;
LORD HIS EXCELLENCY JAMES HRMH [ARCHIVE] /
npub1ej…ehx2v
2023-06-07 18:21:40
in reply to nevent1q…05qn
Author Public Key
npub1ejcm88lhnqwsejncwqxg7nrqgd0r0z29006xd52wvuf9u44xchmqkehx2vPublished at
2023-06-07 18:21:40Event JSON
{
"id": "ec8df5167539a3b8748f3a93e91e738376e2592a5091f6c6d371f54625f95f9f",
"pubkey": "ccb1b39ff7981d0cca78700c8f4c60435e3789457bf466d14e67125e56a6c5f6",
"created_at": 1686162100,
"kind": 1,
"tags": [
[
"e",
"3537067cd11478c8efdc4c102c23b5a7181680d4c1398d745013c38cb5bb9edc",
"",
"root"
],
[
"e",
"d495bc010625aa26fe65ccf3d5430cb288cd4deb7ce66380a5d60a223593cb99",
"",
"reply"
],
[
"p",
"5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803"
]
],
"content": "📅 Original date posted:2019-11-08\n📝 Original message:It goes without saying in that all privately known CVE should be handled so professionally but, that is, well done team.\n\nRegards,\nLORD HIS EXCELLENCY JAMES HRMH\n\n\n________________________________\nFrom: bitcoin-dev-bounces at lists.linuxfoundation.org \u003cbitcoin-dev-bounces at lists.linuxfoundation.org\u003e on behalf of Luke Dashjr via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\nSent: Saturday, 9 November 2019 2:07 AM\nTo: bitcoin-dev at lists.linuxfoundation.org \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\nCc: security at bitcoincore.org \u003csecurity at bitcoincore.org\u003e\nSubject: [bitcoin-dev] CVE-2017-18350 disclosure\n\nCVE-2017-18350 is a buffer overflow vulnerability which allows a malicious\nSOCKS proxy server to overwrite the program stack on systems with a signed\n`char` type (including common 32-bit and 64-bit x86 PCs).\n\nThe vulnerability was introduced in 60a87bce873ce1f76a80b7b8546e83a0cd4e07a5\n(SOCKS5 support) and first released in Bitcoin Core v0.7.0rc1 in 2012 Aug 27.\nA fix was hidden in d90a00eabed0f3f1acea4834ad489484d0012372 (\"Improve and\ndocument SOCKS code\") released in v0.15.1, 2017 Nov 6.\n\nTo be vulnerable, the node must be configured to use such a malicious proxy in\nthe first place. Note that using *any* proxy over an insecure network (such\nas the Internet) is potentially a vulnerability since the connection could be\nintercepted for such a purpose.\n\nUpon a connection request from the node, the malicious proxy would respond\nwith an acknowledgement of a different target domain name than the one\nrequested. Normally this acknowledgement is entirely ignored, but if the\nlength uses the high bit (ie, a length 128-255 inclusive), it will be\ninterpreted by vulnerable versions as a negative number instead. When the\nnegative number is passed to the recv() system call to read the domain name,\nit is converted back to an unsigned/positive number, but at a much wider size\n(typically 32-bit), resulting in an effectively infinite read into and beyond\nthe 256-byte dummy stack buffer.\n\nTo fix this vulnerability, the dummy buffer was changed to an explicitly\nunsigned data type, avoiding the conversion to/from a negative number.\n\nCredit goes to practicalswift (https://twitter.com/practicalswift) for\ndiscovering and providing the initial fix for the vulnerability, and Wladimir\nJ. van der Laan for a disguised version of the fix as well as general cleanup\nto the at-risk code.\n\nTimeline:\n- 2012-04-01: Vulnerability introduced in PR #1141.\n- 2012-05-08: Vulnerability merged to master git repository.\n- 2012-08-27: Vulnerability published in v0.7.0rc1.\n- 2012-09-17: Vulnerability released in v0.7.0.\n...\n- 2017-09-21: practicalswift discloses vulnerability to security team.\n- 2017-09-23: Wladimir opens PR #11397 to quietly fix vulernability.\n- 2017-09-27: Fix merged to master git repository.\n- 2017-10-18: Fix merged to 0.15 git repository.\n- 2017-11-04: Fix published in v0.15.1rc1.\n- 2017-11-09: Fix released in v0.15.1.\n...\n- 2019-06-22: Vulnerability existence disclosed to bitcoin-dev ML.\n- 2019-11-08: Vulnerability details disclosure to bitcoin-dev ML.\n_______________________________________________\nbitcoin-dev mailing list\nbitcoin-dev at lists.linuxfoundation.org\nhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191108/aace00bf/attachment-0001.html\u003e",
"sig": "a759c785ea8b81f97996123aeefac5d72a413645f3900079e7ba933f2f9fbe048b4041d656d69cc01bef0752858f00de17804e952b38b3da2876e70199307c28"
}