public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

* [bitcoin-dev] CVE-2017-18350 disclosure
@ 2019-11-08 15:07 Luke Dashjr
  2019-11-08 17:03 ` LORD HIS EXCELLENCY JAMES HRMH
  0 siblings, 1 reply; 5+ messages in thread
From: Luke Dashjr @ 2019-11-08 15:07 UTC (permalink / raw)
  To: bitcoin-dev; +Cc: security

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.


^ permalink raw reply	[flat|nested] 5+ messages in thread

• * Re: [bitcoin-dev] CVE-2017-18350 disclosure
    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
    0 siblings, 1 reply; 5+ messages in thread
  From: LORD HIS EXCELLENCY JAMES HRMH @ 2019-11-08 17:03 UTC (permalink / raw)
    To: bitcoin-dev, Luke Dashjr; +Cc: security
  
  [-- Attachment #1: Type: text/plain, Size: 3315 bytes --]
  
  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
  
  [-- Attachment #2: Type: text/html, Size: 4761 bytes --]
  
  ^ permalink raw reply	[flat|nested] 5+ messages in thread

• • * Re: [bitcoin-dev] CVE-2017-18350 disclosure
      2019-11-08 17:03 ` LORD HIS EXCELLENCY JAMES HRMH
    @ 2019-11-08 19:40   ` Aymeric Vitte
           [not found]     ` <PS2P216MB0179591B9D8380B290BF4A5C9D7A0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
      0 siblings, 1 reply; 5+ messages in thread
    From: Aymeric Vitte @ 2019-11-08 19:40 UTC (permalink / raw)
      To: LORD HIS EXCELLENCY JAMES HRMH, Bitcoin Protocol Discussion, Luke Dashjr
      Cc: security
    
    [-- 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 --]
    
    ^ permalink raw reply	[flat|nested] 5+ messages in thread

  • • [parent not found: <PS2P216MB0179591B9D8380B290BF4A5C9D7A0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>]

    • • * Re: [bitcoin-dev] CVE-2017-18350 disclosure
               [not found]     ` <PS2P216MB0179591B9D8380B290BF4A5C9D7A0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
        @ 2019-11-09 19:33       ` Aymeric Vitte
               [not found]         ` <PS2P216MB0179B7D2ADEA7CB544F7F90C9D7A0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
          0 siblings, 1 reply; 5+ messages in thread
        From: Aymeric Vitte @ 2019-11-09 19:33 UTC (permalink / raw)
          To: LORD HIS EXCELLENCY JAMES HRMH, Bitcoin Protocol Discussion, Luke Dashjr
          Cc: security
        
        [-- Attachment #1: Type: text/plain, Size: 11613 bytes --]
        
        ???
        
        
        Well, you obviously don't know what you are talking about and did not
        even consider reading correctly what I wrote, neither to read node-Tor
        
        
        What you are saying here is quite trivial, typical of people thinking
        that the Tor network will solve everything and is not centralized (but
        you seem unsure about it), that's not the case, it's completely wrong
        and the "normal" use of the Tor network is for browsing only, basically
        the Tor network is still the same since years: 1000 guards, 1000 relays,
        1000 exits (so not "hundreds", happier, and there are of course
        intersections between them, knowing that they are the supposed working
        nodes as tested by node-Tor), quite small at the end with finally many
        misbehaving nodes among the 3000 set, not at all able or willing to
        handle bitcoin nodes load
        
        
        Using bitcoin with the Tor network is absurd, using socks proxy with
        bitcoin is absurd too (I don't get the comparison with a http proxy,
        nothing to do),  except if limited to a local use, ie you socks proxy
        inside your device, for example to pipe to node-Tor, but this remains as
        a whole dangerous if the local proxy has been hacked, as we could see
        recently with malware Tor sw being used by people
        
        
        Using the Tor protocol for bitcoin is not absurd at all (do you
        understand the difference?) + browsers, webRTC, etc I will not repeat
        what I wrote
        
        
        Please do some readings or consider at least what I sent, or ask
        questions if what I am saying is unclear for you
        
        
        But from my standpoint the discussion on this list is not about
        explaining all of this that is probably well known by everybody but what
        can/could be next to anonymize/help anonymizing bitcoin
        
         when required and make it a real p2p network
        
        
        Unfortunately I am afraid that we get moderated here because that's not
        the place to give basic lessons about Tor that you don't know
        
        
        Le 09/11/2019 à 12:42, LORD HIS EXCELLENCY JAMES HRMH a écrit :
        > Socks proxies have their use in controlled gateway infrastructure and
        > is a relevant feature for any software required to operate behind a
        > secure network boundary and allows for UDP connectivity (whether it is
        > utilised in any particular application) which a HTTP proxy does not.
        >
        > You are obviously not well abreast of the Tor project, regardless of
        > whether it seems centralised, whether it is or it isn't, the Tor
        > project is to allow anonymity and connection privacy. For this it
        > works very well and there seem to be hundreds of known Tor nodes, to
        > be known they are not isolated and are connected.
        >
        > Even if an exit node performs all logging it is only aware of the node
        > one hop up but the originator is higher still. In the case where we
        > perform a Tor cluster and make hundreds of guard, middle and exit
        > nodes we still cannot with absolute certainty say that the connecting
        > node is the originator and, the eventual Bitcoin node is still unaware
        > of the originator IP which is the primary objective. Otherwise, can
        > you hide your IP from your ISP would be a better goal?
        >
        > You may prefer to familiarise yourself first with the history of Tor,
        > even a brief from [WikipediaTor_(anonymity_network)
        > <https://en.wikipedia.org/wiki/Tor_(anonymity_network)>](https://en.wikipedia.org/wiki/Tor_(anonymity_network))
        > and consider some of the possible uses, and consider how its
        > implementation benefits the privacy and anonymity of Bitcoin in public
        > where it is allowed in many countries; Tor is just as useful in
        > countries where Bitcoin is allowed to hide from third-parties. You may
        > also enjoy an example of activating Bitcoin Cores Tor implementation:
        > [How can I setup Bitcoin to be anonymous with
        > Tor?](https://bitcoin.stackexchange.com/questions/70069/how-can-i-setup-bitcoin-to-be-anonymous-with-tor/70070#70070)
        > <https://en.wikipedia.org/wiki/Tor_(anonymity_network)>
        > 	
        > Tor (anonymity network) - Wikipedia
        > <https://en.wikipedia.org/wiki/Tor_(anonymity_network)>
        > Tor is free and open-source software for enabling anonymous
        > communication.The name is derived from an acronym for the original
        > software project name "The Onion Router". Tor directs Internet traffic
        > through a free, worldwide, volunteer overlay network consisting of
        > more than seven thousand relays to conceal a user's location and usage
        > from anyone conducting network surveillance or traffic analysis.
        > en.wikipedia.org
        >
        >
        > <https://bitcoin.stackexchange.com/questions/70069/how-can-i-setup-bitcoin-to-be-anonymous-with-tor/70070#70070>
        > 	
        > bitcoind - How can I setup Bitcoin to be anonymous with Tor? - Bitcoin
        > Stack Exchange
        > <https://bitcoin.stackexchange.com/questions/70069/how-can-i-setup-bitcoin-to-be-anonymous-with-tor/70070#70070>
        > Bitcoin is billed as many things, among them its anonymity is highly
        > regarded. While it is true that a transaction does not identify a user
        > or wallet, recent news shows that there is the potential ...
        > bitcoin.stackexchange.com
        >
        >
        >
        > There should be no rational consideration that gives rise to reducing
        > Tor connectivity, possibly v3 integration will be coming along.
        >
        > Regards,
        > LORD HIS EXCELLENCY JAMES HRMH
        >
        >
        > ------------------------------------------------------------------------
        > *From:* Aymeric Vitte <vitteaymeric@gmail•com>
        > *Sent:* Saturday, 9 November 2019 6:40 AM
        > *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
        >  
        >
        > 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
        >> <mailto:bitcoin-dev-bounces@lists•linuxfoundation.org>
        >> <bitcoin-dev-bounces@lists•linuxfoundation.org>
        >> <mailto:bitcoin-dev-bounces@lists•linuxfoundation.org> on behalf of
        >> Luke Dashjr via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
        >> <mailto:bitcoin-dev@lists•linuxfoundation.org>
        >> *Sent:* Saturday, 9 November 2019 2:07 AM
        >> *To:* bitcoin-dev@lists•linuxfoundation.org
        >> <mailto:bitcoin-dev@lists•linuxfoundation.org>
        >> <bitcoin-dev@lists•linuxfoundation.org>
        >> <mailto:bitcoin-dev@lists•linuxfoundation.org>
        >> *Cc:* security@bitcoincore•org <mailto:security@bitcoincore•org>
        >> <security@bitcoincore•org> <mailto: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
        >> <mailto:bitcoin-dev@lists•linuxfoundation.org>
        >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
        >>
        >> _______________________________________________
        >> bitcoin-dev mailing list
        >> bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>
        >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
        
        
        [-- Attachment #2: Type: text/html, Size: 28141 bytes --]
        
        ^ permalink raw reply	[flat|nested] 5+ messages in thread

      • • [parent not found: <PS2P216MB0179B7D2ADEA7CB544F7F90C9D7A0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>]

        • • * Re: [bitcoin-dev] CVE-2017-18350 disclosure
                   [not found]         ` <PS2P216MB0179B7D2ADEA7CB544F7F90C9D7A0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
            @ 2019-11-10  0:23           ` Aymeric Vitte
              0 siblings, 0 replies; 5+ messages in thread
            From: Aymeric Vitte @ 2019-11-10  0:23 UTC (permalink / raw)
              To: LORD HIS EXCELLENCY JAMES HRMH, Bitcoin Protocol Discussion, Luke Dashjr
              Cc: security
            
            [-- Attachment #1: Type: text/plain, Size: 15465 bytes --]
            
            Do not find excuses (and vague statements or technical bulls) and learn,
            you don't know what you are talking about and don't get the global
            picture, we don't care about the Tor network and they don't care about
            others neither do they care that they increase their network, so indeed
            let's stop this discussion
            
            
            Just replying here (for the last time) because expecting more clever
            thoughts about what I wrote, maybe one day... but for sure something
            like this will happen in the future
            
            
            Le 09/11/2019 à 21:21, LORD HIS EXCELLENCY JAMES HRMH a écrit :
            > We do not need to discuss this back and forward publickly. I am not
            > concerned whether Tors seems or is much centralised or not, it is not
            > the concern of m statements, and it required directory nodes of which
            > there are several and we could discuss the operation of its nodes and
            > infrastructure all day, even comparing directory nodes to seed nodes.
            > The fact is that browsing is the most common publicly understood usage
            > of Tor but like with and without Tor the internet provides many services.
            >
            > It seems you have misunderstood the reason I reference making so many
            > Tor nodes also but do not concern I will no reiterate. Also, whether
            > Tor can provide for the bandwidth and connectivity required for
            > Bitcoin you have not tested and provide only your opinion, where it
            > seems that actually it can. The matter is that Tor carries Bitcoin
            > traffic quite easily now and in fact as there is more Bitcoin traffic
            > likely the Tor capacity increases in some proportion.
            >
            > Also, socks proxy is not a door in, it is a door out, do you realise
            > but just works at a different network layer to HTTP proxy which works
            > at layer 7 of the OSI model and Socks a bit lower?
            >
            > I have had some communication difficulty before where the native
            > language is not English and although the communication happens in
            > native English the though is still being formed in another language
            > and so the presentation of the thought is not clear to the English
            > presentation. Even if not this I do not consider wrong just that we
            > write to consider not the same thing.
            >
            > Good day.
            >
            > Regards,
            > LORD HIS EXCELLENCY JAMES HRMH
            >
            >
            > ------------------------------------------------------------------------
            > *From:* Aymeric Vitte <vitteaymeric@gmail•com>
            > *Sent:* Sunday, 10 November 2019 6:33 AM
            > *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
            >  
            >
            > ???
            >
            >
            > Well, you obviously don't know what you are talking about and did not
            > even consider reading correctly what I wrote, neither to read node-Tor
            >
            >
            > What you are saying here is quite trivial, typical of people thinking
            > that the Tor network will solve everything and is not centralized (but
            > you seem unsure about it), that's not the case, it's completely wrong
            > and the "normal" use of the Tor network is for browsing only,
            > basically the Tor network is still the same since years: 1000 guards,
            > 1000 relays, 1000 exits (so not "hundreds", happier, and there are of
            > course intersections between them, knowing that they are the supposed
            > working nodes as tested by node-Tor), quite small at the end with
            > finally many misbehaving nodes among the 3000 set, not at all able or
            > willing to handle bitcoin nodes load
            >
            >
            > Using bitcoin with the Tor network is absurd, using socks proxy with
            > bitcoin is absurd too (I don't get the comparison with a http proxy,
            > nothing to do),  except if limited to a local use, ie you socks proxy
            > inside your device, for example to pipe to node-Tor, but this remains
            > as a whole dangerous if the local proxy has been hacked, as we could
            > see recently with malware Tor sw being used by people
            >
            >
            > Using the Tor protocol for bitcoin is not absurd at all (do you
            > understand the difference?) + browsers, webRTC, etc I will not repeat
            > what I wrote
            >
            >
            > Please do some readings or consider at least what I sent, or ask
            > questions if what I am saying is unclear for you
            >
            >
            > But from my standpoint the discussion on this list is not about
            > explaining all of this that is probably well known by everybody but
            > what can/could be next to anonymize/help anonymizing bitcoin
            >
            >  when required and make it a real p2p network
            >
            >
            > Unfortunately I am afraid that we get moderated here because that's
            > not the place to give basic lessons about Tor that you don't know
            >
            >
            > Le 09/11/2019 à 12:42, LORD HIS EXCELLENCY JAMES HRMH a écrit :
            >> Socks proxies have their use in controlled gateway infrastructure and
            >> is a relevant feature for any software required to operate behind a
            >> secure network boundary and allows for UDP connectivity (whether it
            >> is utilised in any particular application) which a HTTP proxy does not.
            >>
            >> You are obviously not well abreast of the Tor project, regardless of
            >> whether it seems centralised, whether it is or it isn't, the Tor
            >> project is to allow anonymity and connection privacy. For this it
            >> works very well and there seem to be hundreds of known Tor nodes, to
            >> be known they are not isolated and are connected.
            >>
            >> Even if an exit node performs all logging it is only aware of the
            >> node one hop up but the originator is higher still. In the case where
            >> we perform a Tor cluster and make hundreds of guard, middle and exit
            >> nodes we still cannot with absolute certainty say that the connecting
            >> node is the originator and, the eventual Bitcoin node is still
            >> unaware of the originator IP which is the primary objective.
            >> Otherwise, can you hide your IP from your ISP would be a better goal?
            >>
            >> You may prefer to familiarise yourself first with the history of Tor,
            >> even a brief from [WikipediaTor_(anonymity_network)
            >> <https://en.wikipedia.org/wiki/Tor_(anonymity_network)>](https://en.wikipedia.org/wiki/Tor_(anonymity_network))
            >> and consider some of the possible uses, and consider how its
            >> implementation benefits the privacy and anonymity of Bitcoin in
            >> public where it is allowed in many countries; Tor is just as useful
            >> in countries where Bitcoin is allowed to hide from third-parties. You
            >> may also enjoy an example of activating Bitcoin Cores Tor
            >> implementation: [How can I setup Bitcoin to be anonymous with
            >> Tor?](https://bitcoin.stackexchange.com/questions/70069/how-can-i-setup-bitcoin-to-be-anonymous-with-tor/70070#70070)
            >> <https://en.wikipedia.org/wiki/Tor_(anonymity_network)>
            >> 	
            >> Tor (anonymity network) - Wikipedia
            >> <https://en.wikipedia.org/wiki/Tor_(anonymity_network)>
            >> Tor is free and open-source software for enabling anonymous
            >> communication.The name is derived from an acronym for the original
            >> software project name "The Onion Router". Tor directs Internet
            >> traffic through a free, worldwide, volunteer overlay network
            >> consisting of more than seven thousand relays to conceal a user's
            >> location and usage from anyone conducting network surveillance or
            >> traffic analysis.
            >> en.wikipedia.org
            >>
            >>
            >> <https://bitcoin.stackexchange.com/questions/70069/how-can-i-setup-bitcoin-to-be-anonymous-with-tor/70070#70070>
            >> 	
            >> bitcoind - How can I setup Bitcoin to be anonymous with Tor? -
            >> Bitcoin Stack Exchange
            >> <https://bitcoin.stackexchange.com/questions/70069/how-can-i-setup-bitcoin-to-be-anonymous-with-tor/70070#70070>
            >> Bitcoin is billed as many things, among them its anonymity is highly
            >> regarded. While it is true that a transaction does not identify a
            >> user or wallet, recent news shows that there is the potential ...
            >> bitcoin.stackexchange.com
            >>
            >>
            >>
            >> There should be no rational consideration that gives rise to reducing
            >> Tor connectivity, possibly v3 integration will be coming along.
            >>
            >> Regards,
            >> LORD HIS EXCELLENCY JAMES HRMH
            >>
            >>
            >> ------------------------------------------------------------------------
            >> *From:* Aymeric Vitte <vitteaymeric@gmail•com>
            >> <mailto:vitteaymeric@gmail•com>
            >> *Sent:* Saturday, 9 November 2019 6:40 AM
            >> *To:* LORD HIS EXCELLENCY JAMES HRMH <willtech@live•com.au>
            >> <mailto:willtech@live•com.au>; Bitcoin Protocol Discussion
            >> <bitcoin-dev@lists•linuxfoundation.org>
            >> <mailto:bitcoin-dev@lists•linuxfoundation.org>; Luke Dashjr
            >> <luke@dashjr•org> <mailto:luke@dashjr•org>
            >> *Cc:* security@bitcoincore•org <mailto:security@bitcoincore•org>
            >> <security@bitcoincore•org> <mailto:security@bitcoincore•org>
            >> *Subject:* Re: [bitcoin-dev] CVE-2017-18350 disclosure
            >>  
            >>
            >> 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
            >> <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
            >>> <mailto:bitcoin-dev-bounces@lists•linuxfoundation.org>
            >>> <bitcoin-dev-bounces@lists•linuxfoundation.org>
            >>> <mailto:bitcoin-dev-bounces@lists•linuxfoundation.org> on behalf of
            >>> Luke Dashjr via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
            >>> <mailto:bitcoin-dev@lists•linuxfoundation.org>
            >>> *Sent:* Saturday, 9 November 2019 2:07 AM
            >>> *To:* bitcoin-dev@lists•linuxfoundation.org
            >>> <mailto:bitcoin-dev@lists•linuxfoundation.org>
            >>> <bitcoin-dev@lists•linuxfoundation.org>
            >>> <mailto:bitcoin-dev@lists•linuxfoundation.org>
            >>> *Cc:* security@bitcoincore•org <mailto:security@bitcoincore•org>
            >>> <security@bitcoincore•org> <mailto: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
            >>> <mailto:bitcoin-dev@lists•linuxfoundation.org>
            >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
            >>>
            >>> _______________________________________________
            >>> bitcoin-dev mailing list
            >>> bitcoin-dev@lists•linuxfoundation.org <mailto: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: 41190 bytes --]
            
            ^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2019-11-10  0:23 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
     [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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox