Deja Vu Releases Case Study For Their Ethereum Security Review

Comments

  • GeorgeHallamGeorgeHallam Member, Administrator, Moderator Posts: 229 admin
    From the post:

    Deja vu Security, LLC, is excited to announce its contribution in the release of the ethereum project, a development platform that offers great promise and uses second-generation blockchain technology. Applications built upon this platform include, but are not limited to, financial products and derivatives, contract systems, health record systems, file storage applications, as well as voting and governance applications. As this is a nascent technology, many use cases may yet be undiscovered.

    The security assessment consisted of many reviews, including of a design review, a solutions review, reviews of a protocol and a quasi-Turing-complete virtual machine of the clients, with appropriate tests using the industry-leading Peach Fuzzer® platform.

    The results were stellar. Ethereum is excited about their launch and, according to Jeffrey Wilcke, Ethereum Director and Chief of the Mist and Go client projects, “We were able to resolve severe issues only with your help for which we are incredibly grateful.”
  • tym4ttym4t Nagata-ku, Kobe-shi, Hyogo-ken, JapanMember Posts: 71 ✭✭✭
    Is there a detailed report of the actual audit for public consumption? This would be useful for others who are creating their own client implementation.
  • GeorgeHallamGeorgeHallam Member, Administrator, Moderator Posts: 229 admin
    We are currently discussing the publishing of a report summary - this makes sense as 90% of the actual report is pretty esoteric to the uninitiated :)
  • paleh0rsepaleh0rse Member Posts: 5
    edited July 2015

    We are currently discussing the publishing of a report summary - this makes sense as 90% of the actual report is pretty esoteric to the uninitiated :)

    That's a fairly lousy response to the request. Some of us are scientists who read and write similar audits for a living; so, I don't think you should assume that we're all "uninitiated," or that none of us would benefit from reviewing the "actual report."

    I too would like to see the complete audit published for public consumption; and sooner, rather than later.
    Post edited by paleh0rse on
  • GeorgeHallamGeorgeHallam Member, Administrator, Moderator Posts: 229 admin
    When we discussed our approach to the security audit and negotiated agreements a few months ago, one of our goals was to make the audits and results as transparent as possible – e.g. to allow security researchers and other developers to build on what we would learn together with the auditors.

    As you might know from your own work as a researcher, during and audit various notes and documents are created that serve to document processes or for communication between the parties involved. Not all of them can be understood easily without context – independent of the level of expertise in the particular field of security of information technology. They are process documents intended for the involved parties to communicate and might also contain information about proprietary tools employed that are not for everyone’s eyes. As you might expect such documents are not intended for publication according to contractual terms – I suppose you likewise don’t publish for example emails you exchanged with your clients after an audit.

    In that sense the publishing of the Least Authority “report” also only represented the publication of a final report summarizing the eventual results of the audit.

    Our contract with Deja vu Security did not contain terms for the creation of a similar summary report. The audit was much more process heavy (as described in Jutta’s post) with corresponding documents being created weekly that were collated together with some overall comments and notes in the final report document shared with us.

    To make the results of the Deja vu audit accessible as early as possible to a wider audience (and as already mentioned in Jutta’s post), we openly tracked the related GH issues with a special tag, more precisely the SEC- prefix. Furthermore we have asked Deja vu Security to put together a summary to address the communities’ and researchers’ interests – we will keep you posted.

    If you have questions regarding particular issues please get in touch with Dr. Jutta Steiner. We would be very grateful to hear your opinion if you differ with our or Deja vu’s judgement on specific issues. As we are, I’m sure Deja vu would be very happy to discuss issues further...
  • gustav_simonssongustav_simonsson Member, Moderator Posts: 21 mod
    The most essential technical detail of the deja vu findings can indeed be found in the "SEC" issues in the go-ethereum repo. You can also ping me about specific issues if you are interested, as I've been tracking them during the audits and helped out with fixes for them.
  • paleh0rsepaleh0rse Member Posts: 5
    edited July 2015

    The most essential technical detail of the deja vu findings can indeed be found in the "SEC" issues in the go-ethereum repo. You can also ping me about specific issues if you are interested, as I've been tracking them during the audits and helped out with fixes for them.

    Are there (or were there) any security-related findings that don't/didn't have a corresponding SEC tag on GH?

    Many of the audit categories listed in the summary would result in analysis or findings not really suitable for GH -- Design Review; Solution Review; Protocol, P2P, and Network Review, etc. -- so I'm curious where all of those findings are? I'm personally much more interested in those than the code reviews.
    Post edited by paleh0rse on
  • gustav_simonssongustav_simonsson Member, Moderator Posts: 21 mod
    @paleh0rse Yepp, the full list for the Go client is under the "vuln" label for which the "SEC" issues are a subset: https://github.com/ethereum/go-ethereum/issues?utf8=✓&q=is:issue+label:vuln

    Analysis / findings that were more broad and not captured by individual GH issues is for example: https://github.com/ethereum/wiki/wiki/Proposal:-BlockHashesFromNumbers

    This was a proposal from auditors to avoid potential DoS cases and make it easier for clients to implement peer logic.

    Another general recommendation is that currently the Go client is not well designed to process multiple forks simultaneously which can cause problems when the chain head is switching back and forth a lot. The discussion was to divorce block processing from node state, maintaining multiple separate chains simultaneously where the chain head is just a pointer to one specific block (instead of the current approach that removes blocks from the "head" state).

    Another recommendation is to avoid the current peer fixation, where the Go client chooses a single peer for blockchain sync based on advertised total difficulty (TD) (which can be faked). The peer handling has logic to prevent DoS from malicious peer faking his TD, which could be removed if we avoided using advertised TD and instead download each peer's perspective of the blockchain.

    There are a few more such general discussions / recommendations which I hope we can make public in some form soon.
  • paleh0rsepaleh0rse Member Posts: 5
    edited July 2015
    Excellent, thank you for the info. I'll check it out now, and I look forward to seeing the additional discussions soon.
  • tym4ttym4t Nagata-ku, Kobe-shi, Hyogo-ken, JapanMember Posts: 71 ✭✭✭

    We are currently discussing the publishing of a report summary - this makes sense as 90% of the actual report is pretty esoteric to the uninitiated :)

    Well considering I was actually part of the team that developed ASLR back in the 90s some would consider myself an initiate when it comes to these matters. B)
Sign In or Register to comment.