Dear All, To what extent do we think that Beast should be "secure"? I am thinking mostly about handling malicious input. Has it been reviewed by anyone with specific experience of how HTTP can be attacked? Has it been "fuzzed"? Regards, Phil.
On Mon, Jul 3, 2017 at 9:42 AM, Phil Endecott via Boost <boost@lists.boost.org> wrote:
Has it been reviewed by anyone with specific experience of how HTTP can be attacked? Has it been "fuzzed"?
I would love for someone to do a security audit and in the absence of a volunteer I will likely take on the expense myself. That said, I have made the tests quite extensive. 100% code coverage is always an ongoing goal. All branches which handle failure are checked, and there is a concept called "bufgrind" where all possible 2-buffer combinations of inputs are tested. This means for a message of size N it is split up into two buffers x and N-x and fed to the parser. You can see that stuff here: https://github.com/vinniefalco/Beast/blob/78a065ba39836d91d7e70d93de7f9140f5... https://github.com/vinniefalco/Beast/blob/78a065ba39836d91d7e70d93de7f9140f5... https://github.com/vinniefalco/Beast/blob/78a065ba39836d91d7e70d93de7f9140f5... You can see that coverage is extremely high: https://codecov.io/gh/vinniefalco/Beast/src/review/include/beast/http/impl/b... Note that the review branch is missing some tests which I have since added, so actual coverage is higher than what is displayed here.
Vinnie Falco via Boost wrote:
I would love for someone to do a security audit and in the absence of a volunteer I will likely take on the expense myself.
That said, I have made the tests quite extensive. 100% code coverage is always an ongoing goal.
Perhaps you could also add a Coverity scan to the list as well: https://scan.coverity.com/ It's not a security oriented analysis per-say but it may catch certain problems through static analysis they could lead to security issues down the track.
On Mon, Jul 3, 2017 at 10:14 AM Arash Partow via Boost < boost@lists.boost.org> wrote:
Perhaps you could also add a Coverity scan to the list as well:
Yes I have seen that. The problem is that the blatantly commercial nature and build limits turns me off to it. Beast Travis scrips run every branch and pulll request through valgrind, and a separate address sanitizer and undefined behavior sanitizer. You can see it here <https://travis-ci.org/vinniefalco/Beast/jobs/248185460> <https://travis-ci.org/vinniefalco/Beast/jobs/248185461> Thanks -- -------------------------------------------------- On Sun, Jul 2, 2017 at 8:55 AM, Niall Douglas wrote:
..you say Beast should not provide functions to send and receive HTTP messages using Asio streams?
Absolutely correct.
Follow me on Github: https://github.com/vinniefalco
On Mon, Jul 3, 2017 at 10:14 AM Arash Partow via Boost < boost@lists.boost.org> wrote:
https://scan.coverity.com/ /listinfo.cgi/boost <http://lists.boost.org/mailman/listinfo.cgi/boost>
Forgot to mention, Ripple (which uses beast) uses coverity and the only thing that came out of it was a bunch of false positives. If someone wants to submit a pull request to enable integrating with their CI system I would accept it though. -- -------------------------------------------------- On Sun, Jul 2, 2017 at 8:55 AM, Niall Douglas wrote:
..you say Beast should not provide functions to send and receive HTTP messages using Asio streams?
Absolutely correct.
Follow me on Github: https://github.com/vinniefalco
On Mon, Jul 3, 2017 at 7:47 PM, Vinnie Falco via Boost <boost@lists.boost.org> wrote:
On Mon, Jul 3, 2017 at 9:42 AM, Phil Endecott via Boost <boost@lists.boost.org> wrote:
Has it been reviewed by anyone with specific experience of how HTTP can be attacked? Has it been "fuzzed"?
I would love for someone to do a security audit and in the absence of a volunteer I will likely take on the expense myself.
That said, I have made the tests quite extensive. 100% code coverage is always an ongoing goal. All branches which handle failure are checked,
I must say that security in WWW worlds is tricky thing to check. Also stuff like buffer overruns or integer overflows are common they are relatively simple to check using unit tests. The bigger problem is the stuff you do not check or assume already validated. Also Beast is too low level library to worry about CSRF or XSS. It still provides virtually no validation of what is going on automatically. No timeouts, no content-length till few days ago. It may give some sort of false security to user that may not be aware of wide range of potential issues around. This kind of design should provide a huge warning notice to all end users - all we do is parse protocol - the rest is up to you (which is 99% of all security stuff related to WWW) Artyom
On Mon, Jul 3, 2017 at 12:12 PM Artyom Beilis via Boost < boost@lists.boost.org> wrote:
This kind of design should provide a huge warning notice to all end users - all we do is parse protocol - the rest is up to you (which is 99% of all security stuff related to WWW)
I agree completely; you have accurately characterized the library. -- -------------------------------------------------- On Sun, Jul 2, 2017 at 8:55 AM, Niall Douglas wrote:
..you say Beast should not provide functions to send and receive HTTP messages using Asio streams?
Absolutely correct.
Follow me on Github: https://github.com/vinniefalco
On Mon, Jul 3, 2017 at 9:42 AM, Phil Endecott via Boost <boost@lists.boost.org> wrote:
To what extent do we think that Beast should be "secure"? I am thinking mostly about handling malicious input.
Has it been reviewed by anyone with specific experience of how HTTP can be attacked? Has it been "fuzzed"?
We now have the answer to this question: <https://vinniefalco.github.io/BeastAssets/Beast%20-%20Hybrid%20Application%20Assessment%202017%20-%20Assessment%20Report%20-%2020171114.pdf> Linked from <http://www.boost.org/doc/libs/master/libs/beast/doc/html/beast/reports.html#beast.reports.security_review_bishop_fox> Bishop Fox did find one serious vulnerability in the processing of compressed websocket frames. This flaw was fixed in time for Boost 1.66.0. Thanks
On Tue, Dec 12, 2017 at 7:26 PM, Vinnie Falco via Boost < boost@lists.boost.org> wrote:
On Mon, Jul 3, 2017 at 9:42 AM, Phil Endecott via Boost <boost@lists.boost.org> wrote:
To what extent do we think that Beast should be "secure"? I am thinking mostly about handling malicious input.
Has it been reviewed by anyone with specific experience of how HTTP can be attacked? Has it been "fuzzed"?
We now have the answer to this question:
<https://vinniefalco.github.io/BeastAssets/Beast%20-% 20Hybrid%20Application%20Assessment%202017%20-%20Assessment%20Report%20-% 2020171114.pdf>
Linked from
<http://www.boost.org/doc/libs/master/libs/beast/doc/ html/beast/reports.html#beast.reports.security_review_bishop_fox>
Bishop Fox did find one serious vulnerability in the processing of compressed websocket frames. This flaw was fixed in time for Boost 1.66.0.
I can heartily recommend the project OSS-Fuzz. https://github.com/google/oss-fuzz You figure out how to apply a byte stream to a call in your library, and they fuzz it. Over and over. Forever. I have hooked up several of the calls in libc++ (sorting, heap operations, regex parsers) and it has found a few bugs (all in the regex stuff) I'm glad to show people how to get started with this. -- Marshall
On Tue, Dec 12, 2017 at 8:57 PM, Marshall Clow via Boost <boost@lists.boost.org> wrote:
I can heartily recommend the project OSS-Fuzz. https://github.com/google/oss-fuzz
Lets not bury the lede here. It is great that I have personally fuzzed Beast and written extensive tests with high coverage but the point of the report is that Beast has been investigated by an impartial third party who specializes in security reviews. Thanks
On Wed, Dec 13, 2017 at 8:21 AM, Vinnie Falco via Boost < boost@lists.boost.org> wrote:
On Tue, Dec 12, 2017 at 8:57 PM, Marshall Clow via Boost <boost@lists.boost.org> wrote:
I can heartily recommend the project OSS-Fuzz. https://github.com/google/oss-fuzz
Lets not bury the lede here. It is great that I have personally fuzzed Beast and written extensive tests with high coverage but the point of the report is that Beast has been investigated by an impartial third party who specializes in security reviews.
That is indeed a very good development. I wish other libraries could get such security treatment. It might be worth investigating if we can get sponsors to perform such audits on other libraries in exchange for a mention along side the audit report. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net
participants (6)
-
Arash Partow -
Artyom Beilis -
Marshall Clow -
Phil Endecott -
Rene Rivera -
Vinnie Falco