public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Mike Hearn <mike@plan99.net>
To: Jeff Garzik <jgarzik@bitpay.com>
Cc: Nicolas DORIER <nicolas.dorier@gmail.com>,
	Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?
Date: Wed, 28 Jan 2015 18:45:10 +0100	[thread overview]
Message-ID: <CANEZrP3GgDYiHt+grWjX+gpDDh9HUvPDGLqi-mpgddEMd24q7w@mail.gmail.com> (raw)
In-Reply-To: <CAJHLa0MCyzm_t47R5Z5MPL9ruqM=uq15u26W3dwRsBy57K11=w@mail.gmail.com>

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

>
> It is not "fear", it is field experience.
>
> JSON has proven to be a bug generator for the reasons already stated.
>

To back Jeff up on this point, today we see this story:

http://www.theregister.co.uk/2015/01/27/trivial_hole_left_black_phones_open_to_plunder/

The maker of BlackPhone – a mobile marketed as offering unusually high
levels of security – has patched *a critical vulnerability that allows
hackers to run malicious code on the handsets*. Attackers need little more
than a phone number to send a message that can compromise the devices via
the Silent Text application.

"The SCIMP protocol encodes messages as JSON objects, which are then
transmitted to the remote party over XMPP," Dowd explained to *The Register*.
"*The flaw I discovered occurs during the deserialization of these JSON
objects*. It is *a type confusion vulnerability*, which when exploited
allows an attacker to overwrite a pointer in memory, either partially or in
full. This pointer is later manipulated by the program and also the system
allocator, allowing you to do things such as pass arbitrary pointers to
free()."

The C++/Java/Python protocol buffer implementations are used by Google for
all internal inter-server communication. Any similar exploit in them would
result in total bypass of their entire internal security and auditing
system by allowing you to run code as any user. The Google security team is
very good, the protobuf code is carefully reviewed and the format is
relatively constrained. The chances of there being any security problems in
the parsing code generated by the protobuf compilers is drastically
smaller. As BIP70 requests are parsed by security sensitive code, this
matters.

The vision for BIP70 has always been to be a foundation for many features.
We haven't really done much with it so far because there have always been
higher priorities. But I hope that if Bitcoin continues to be successful
and grows, one day payment requests will have many different features in
them and those will likely include many complex data structures.

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

  reply	other threads:[~2015-01-28 17:45 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-28 12:45 [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding? Nicolas DORIER
2015-01-28 13:32 ` Wladimir
2015-01-28 14:00   ` Nicolas DORIER
2015-01-28 15:42     ` Mike Hearn
2015-01-28 16:04       ` Jeff Garzik
2015-01-28 16:52         ` Nicolas DORIER
2015-01-28 17:29           ` Jeff Garzik
2015-01-28 17:45             ` Mike Hearn [this message]
2015-01-28 16:19       ` Giuseppe Mazzotta
2015-01-28 16:51         ` Matt Whitlock
2015-01-28 17:02           ` Mike Hearn
2015-01-28 16:34       ` Nicolas DORIER
2015-01-28 16:55         ` Mike Hearn
2015-01-28 17:04           ` Nicolas Dorier
2015-01-28 17:14             ` Mike Hearn
2015-01-28 17:17               ` Angel Leon
2015-01-28 17:27               ` Nicolas DORIER
  -- strict thread matches above, loose matches on Subject: below --
2015-01-19 19:07 Richard Brady
2015-01-19 19:09 ` Jeff Garzik
2015-01-19 19:16   ` Richard Brady
2015-01-19 19:34     ` Jeff Garzik
2015-01-19 19:48   ` Peter Todd
2015-01-19 19:57     ` Richard Brady
2015-01-19 20:03       ` Alan Reiner
2015-01-19 20:06         ` Peter Todd
2015-01-19 20:40         ` Mike Hearn
2015-01-19 20:56           ` Gavin Andresen
2015-01-19 21:22             ` Brian Hoffman
2015-01-19 20:59           ` Ross Nicoll
2015-01-24 13:19           ` Isidor Zeuner
2015-01-25 22:59             ` Ross Nicoll
2015-03-14 15:58             ` Isidor Zeuner
2015-03-24 12:08               ` Jorge Timón
2015-01-19 21:21         ` Jeff Garzik
2015-01-19 19:19 ` Matt Whitlock
2015-01-19 19:37   ` Mike Hearn
2015-01-19 19:38   ` Jeff Garzik

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=CANEZrP3GgDYiHt+grWjX+gpDDh9HUvPDGLqi-mpgddEMd24q7w@mail.gmail.com \
    --to=mike@plan99.net \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=jgarzik@bitpay.com \
    --cc=nicolas.dorier@gmail.com \
    /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