[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #5837 [Tor bundles/installation]: Use IDA Pro and/or BinDiff to inspect releases



#5837: Use IDA Pro and/or BinDiff to inspect releases
--------------------------------------+-------------------------------------
 Reporter:  mikeperry                 |          Owner:  cypherpunks
     Type:  project                   |         Status:  new        
 Priority:  major                     |      Milestone:             
Component:  Tor bundles/installation  |        Version:             
 Keywords:  volunteer                 |         Parent:  #5292      
   Points:                            |   Actualpoints:             
--------------------------------------+-------------------------------------

Old description:

> We have some concerning issues with our build processes. It's hard to
> really know for sure that the build machines are secure and not tampered
> with. See for example #5689. The most likely situation there is that AV
> signature engines fucking suck, and were false positives. However, the
> real fix is not simply scanning the build machines with more shitty AV
> software (although it was a fine, rational first step -- I'm not hating
> on you, Erinn). The real fix is unfortunately much harder: We need to
> ensure that the same source produces the same binaries everywhere: #3688.
>
> Other than build reproduction, it's nearly fucking impossible to know
> that the binaries you get actually come from the source you wrote and
> audited. A handful of Open Source projects have figured it out (see
> comments in #3688), but it's actually pretty darn hard on Windows, if not
> impossible.
>
> As a stop-gap solution, it's occurred to me that we might be able to
> crowdsource hobbyists and people looking to learn reversing (or if we're
> really lucky, some people who already have these skills) to both help
> verify previous builds, and give us the input we need to proceed on
> #3688.
>
> If you have access to IDA Pro
> ([http://blog.zynamics.com/2011/12/05/bindiff-4-0-available-today/
> BinDiff] will help, but is an extra $200 extension to IDA Pro and is not
> required), you can participate as follows:
>

> 1. Download a signed TBB release from
> https://www.torproject.org/dist/torbrowser/.
>
> 2. Compile your own TBB bundle. This is somewhat tricky. Sebastian has
> instructions for Mac OS in
> https://gitweb.torproject.org/torbrowser.git/tree/master:/docs/buildmachine_setups.
> Windows and Linux instructions should arrive there soon.
>
> If you succeed in producing an independent build, it will be useful to
> post a link to it here for others to begin analyzing. However, you'll
> want to use a VM when inspecting random anonymous people's builds: IDA
> Pro is of course not immune to exploits against itself.
>
> 3. BinDiff the resulting packaging exe as well as the exes contained
> therein.
>
> If you lack BinDiff, you should consider focusing your efforts on MacOS
> and Linux packages, which should produce substantially more similar
> builds than Windows, especially if you build the Linux TBB on Debian
> Lenny and the Mac one on MacOS 10.7 with Xcode 4 (which are our build
> machine setups). Start with using the 'cmp' (and/or hexdump and diff)
> UNIX commands to find the differing sections of the binaries, and then
> use IDA Pro to inspect those sections. More advanced tools to find
> minimal binary edit differences may also be useful if the differences the
> basic tools find are large. http://jojodiff.sourceforge.net/ is an
> example of one such tool, but there probably are others.
>
> You should be able to use IDA Pro for any platform to analyze binaries
> for any other platform. You do not need to buy the MacOS copy to analyze
> MacOS binaries.
>
> 4. Use normal UNIX diff on the non-exe components (for example, conf
> files, shell scripts, contents of Firefox jars and addon sources).
>
> 5. Write up the significant differences.
>

> We need to make the above a semi-regular part of our development process
> to periodically verify our build integrity.
>
> Writing up the differences you find will also be useful for us to help us
> work towards #3688, especially for Mac and Linux builds (which are likely
> pretty darn close.. It's probably only some timestamps and symbol names
> that differ if you use the same platform and compiler).
>
> If you want to be extra-helpful, you can write up a detailed howto
> (and/or just paste the ones you find that already exist) on the process
> itself to make it even easier for others to learn and participate.
>
> We'll need to do this often.. Perhaps not for every release, but at least
> randomly on some builds every once and a while. Also, BinDiffing archived
> signed TBB copies from https://archive.torproject.org/tor-package-
> archive/torbrowser/ will be useful, too, so no need to wait for future
> releases. You can start today. The source tarballs are in that directory
> as well, with -src.tar.gz instead of a language and arch. However, to get
> the actual git sources for an old release:
>
> {{{
> git clone git://git.torproject.org/torbrowser.git
> cd torbrowser
> git tag -l
> git checkout torbrowser-2.2.35-9.1
> }}}
>
> Git will tell you that you can't commit anything that way, but that
> shouldn't matter to you.
>
> Note that this whole process is a fantastic exercise in learning basic
> reverse engineering skills. Diffing vendor patches and malware updates is
> a common practice in the field. It's a useful skill to learn, if you have
> the time.
>
> Good luck!

New description:

 We have some concerning issues with our build processes. It's hard to
 really know for sure that the build machines are secure and not tampered
 with. See for example #5689. The most likely situation there is that AV
 signature engines fucking suck, and were false positives. However, the
 real fix is not simply scanning the build machines with more shitty AV
 software (although it was a fine, rational first step -- I'm not hating on
 you, Erinn). The real fix is unfortunately much harder: We need to ensure
 that the same source produces the same binaries everywhere: #3688.

 Other than build reproduction, it's nearly fucking impossible to know that
 the binaries you get actually come from the source you wrote and audited.
 A handful of Open Source projects have figured it out (see comments in
 #3688), but it's actually pretty darn hard on Windows, if not impossible.

 As a stop-gap solution, it's occurred to me that we might be able to
 crowdsource hobbyists and people looking to learn reversing (or if we're
 really lucky, some people who already have these skills) to both help
 verify previous builds, and give us the input we need to proceed on #3688.

 If you have access to IDA Pro
 ([http://blog.zynamics.com/2011/12/05/bindiff-4-0-available-today/
 BinDiff] will help, but is an extra $200 extension to IDA Pro and is not
 required), you can participate as follows:


 1. Download a signed TBB release from
 https://www.torproject.org/dist/torbrowser/.

 2. Compile your own TBB bundle. This is somewhat tricky. Sebastian has
 instructions for Mac OS in
 https://gitweb.torproject.org/torbrowser.git/tree/master:/docs/buildmachine_setups.
 Windows and Linux instructions should arrive there soon.

 3. Analyze/BinDiff the resulting packaging exe as well as the exes
 contained therein.

 If you lack BinDiff, you should consider focusing your efforts on MacOS
 and Linux packages, which should produce substantially more similar builds
 than Windows, especially if you build the Linux TBB on Debian Lenny and
 the Mac one on MacOS 10.7 with Xcode 4 (which are our build machine
 setups). Start with using the 'cmp' (and/or hexdump and diff) UNIX
 commands to find the differing sections of the binaries, and then use IDA
 Pro to inspect those sections (quickest way: Just use the search tool for
 a long hex string surrounding the difference).

 More advanced tools to find minimal binary edit differences may also be
 useful if the differences the basic tools find are large.
 http://jojodiff.sourceforge.net/ is an example of one such tool, but there
 probably are others.

 Be sure to verify the difference that IDA and/or BinDiff decodes is the
 same as a simple diff tool finds (cmp or jojodiff). The simple diff tool
 is less likely to be fooled than IDA.

 You should be able to use IDA Pro for any platform to analyze binaries for
 any other platform. You do not need to buy the MacOS copy to analyze MacOS
 binaries.

 4. Use normal UNIX diff on the non-exe components (for example, conf
 files, shell scripts, contents of Firefox jars and addon sources).

 5. Write up the significant differences.


 We need to make the above a semi-regular part of our development process
 to periodically verify our build integrity.

 Writing up the differences you find will also be useful for us to help us
 work towards #3688, especially for Mac and Linux builds (which are likely
 pretty darn close.. It's probably only some timestamps and symbol names
 that differ if you use the same platform and compiler).

 If you want to be extra-helpful, you can write up a detailed howto (and/or
 just paste the ones you find that already exist) on the process itself to
 make it even easier for others to learn and participate.

 We'll need to do this often.. Perhaps not for every release, but at least
 randomly on some builds every once and a while. Also, BinDiffing archived
 signed TBB copies from https://archive.torproject.org/tor-package-
 archive/torbrowser/ will be useful, too, so no need to wait for future
 releases. You can start today. The source tarballs are in that directory
 as well, with -src.tar.gz instead of a language and arch. However, to get
 the actual git sources for an old release:

 {{{
 git clone git://git.torproject.org/torbrowser.git
 cd torbrowser
 git tag -l
 git checkout torbrowser-2.2.35-9.1
 }}}

 Git will tell you that you can't commit anything that way, but that
 shouldn't matter to you.

 Note that this whole process is a fantastic exercise in learning basic
 reverse engineering skills. Diffing vendor patches and malware updates is
 a common practice in the field. It's a useful skill to learn, if you have
 the time.

 Good luck!

--

Comment(by mikeperry):

 Changes to description: Give a few more hints to illuminate the diffing
 process. We may not actually want to rely fully on what BinDiff and IDA
 say.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5837#comment:9>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs