[beast] Security

newer
Building only x86 /MDd and /MT on...

Phil Endecott

3 Jul 2017 3 Jul '17

4:42 p.m.

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.

Show replies by date

Vinnie Falco

3 Jul 3 Jul

4:47 p.m.

On Mon, Jul 3, 2017 at 9:42 AM, Phil Endecott via Boost 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.

Arash Partow

5:13 p.m.

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.

Vinnie Falco

5:25 p.m.

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:

https://scan.coverity.com/

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

Vinnie Falco

5:40 p.m.

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

Artyom Beilis

7:12 p.m.

On Mon, Jul 3, 2017 at 7:47 PM, Vinnie Falco via Boost wrote:

...

On Mon, Jul 3, 2017 at 9:42 AM, Phil Endecott via Boost 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

Vinnie Falco

7:21 p.m.

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

Vinnie Falco

13 Dec 13 Dec

3:26 a.m.

On Mon, Jul 3, 2017 at 9:42 AM, Phil Endecott via Boost 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%2... Linked from http://www.boost.org/doc/libs/master/libs/beast/doc/html/beast/reports.html#... 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

Marshall Clow

4:57 a.m.

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 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

Vinnie Falco

2:21 p.m.

On Tue, Dec 12, 2017 at 8:57 PM, Marshall Clow via Boost 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

Rene Rivera

3:03 p.m.

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 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

2540

Age (days ago)

2703

Last active (days ago)

List overview

Download

10 comments

6 participants

participants (6)

Arash Partow
Artyom Beilis
Marshall Clow
Phil Endecott
Rene Rivera
Vinnie Falco

[beast] Security

Phil Endecott

Vinnie Falco

Arash Partow

Vinnie Falco

Vinnie Falco

Artyom Beilis

Vinnie Falco

Vinnie Falco

Marshall Clow

Vinnie Falco

Rene Rivera

tags

participants (6)