public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Aymeric Vitte <vitteaymeric@gmail.com>
To: LORD HIS EXCELLENCY JAMES HRMH <willtech@live.com.au>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>,
	Luke Dashjr <luke@dashjr.org>
Cc: "security@bitcoincore.org" <security@bitcoincore.org>
Subject: Re: [bitcoin-dev] CVE-2017-18350 disclosure
Date: Fri, 8 Nov 2019 20:40:17 +0100	[thread overview]
Message-ID: <b6ccd41b-3232-80d2-ab66-5ffa0f7abfac@gmail.com> (raw)
In-Reply-To: <PS2P216MB0179D441FBC93122CDE5354D9D7B0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>

[-- Attachment #1: Type: text/plain, Size: 6099 bytes --]

Sure, but what is questionable here is the use of SOCKS proxy, for Tor I
think as the main purpose, making it dangerous for the "whole bitcoin
world" while it's something like of zero interest/use (or please let me
know what it is beside Tor)

The Tor network is very centralized and not designed at all to handle
p2p networks (which bitcoin is still not), it is designed to be used via
the Tor Browser to browse the web and to hide web servers, not bitcoin
nodes, and there are a lot of misbehaving/dangerous nodes there, there
is no encryption in bitcoin protocol, an exit node can fake whatever it
likes, this seems to be a use case as far as I can see, but even if the
initiator is configured to connect to a hidden bitcoin node, I don't see
the point

I have advertised recentlty the open sourcing of node-Tor
(https://github.com/Ayms/node-Tor) here

This one is designed for p2p, not over the Tor network but using the Tor
protocol, as simple as bitcoin.pipe(node-Tor), or <any
protocol>.pipe(node-Tor), which is the finality of the project as far as
I see it since years (maybe see http://www.peersm.com/Convergence.pdf
even if I would modify some parts now)

Inside servers or browsers acting as servers also (WebRTC or
WebSockets), bitcoin peers (servers/browsers) relaying the bitcoin
anonymized protocol using the Tor protocol (and not the Tor network)
between each others, there is no story of exit nodes here and rdv points
would not apply for bitcoin use, this "just" adds the internal missing
encryption and anonymity layer to the bitcoin protocol

Personally I would remove the socks proxy interface from bitcoin core,
independently of Tor this can be misused too and offers absolutely zero
security


Le 08/11/2019 à 18:03, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev a
écrit :
> 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@lists.linuxfoundation.org
> <bitcoin-dev-bounces@lists.linuxfoundation.org> on behalf of Luke
> Dashjr via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
> *Sent:* Saturday, 9 November 2019 2:07 AM
> *To:* bitcoin-dev@lists.linuxfoundation.org
> <bitcoin-dev@lists.linuxfoundation.org>
> *Cc:* security@bitcoincore.org <security@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-- 
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms


[-- Attachment #2: Type: text/html, Size: 11965 bytes --]

  reply	other threads:[~2019-11-08 19:40 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-08 15:07 [bitcoin-dev] CVE-2017-18350 disclosure Luke Dashjr
2019-11-08 17:03 ` LORD HIS EXCELLENCY JAMES HRMH
2019-11-08 19:40   ` Aymeric Vitte [this message]
     [not found]     ` <PS2P216MB0179591B9D8380B290BF4A5C9D7A0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
2019-11-09 19:33       ` Aymeric Vitte
     [not found]         ` <PS2P216MB0179B7D2ADEA7CB544F7F90C9D7A0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
2019-11-10  0:23           ` Aymeric Vitte

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b6ccd41b-3232-80d2-ab66-5ffa0f7abfac@gmail.com \
    --to=vitteaymeric@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=luke@dashjr.org \
    --cc=security@bitcoincore.org \
    --cc=willtech@live.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox