
NetBSD Network Security Audit - ognyankulev
http://blog.netbsd.org/tnf/entry/network_security_audit
======
Panino
Maxime Villard has been doing great work finding lots of bugs, many with a
code scanner he wrote called Brainy. As an OpenBSD user I've been watching
with interest from the sidelines. More info on Brainy results:

[https://www.m00nbsd.net/474b193ce624a19d39a2286d73f06826.htm...](https://www.m00nbsd.net/474b193ce624a19d39a2286d73f06826.html)

Take a look! There is likely software that you use in the list - for instance,
one of the bugs is a memleak in OpenSSH.

I don't use NetBSD but I just donated $20 to the NetBSD Foundation anyway.
Thanks for sharing code/patches!

~~~
badsectoracula
What is this site supposed to show? There isn't any information/documentation
about Brainy, what it is all about or even a way to download it.

~~~
temprature
Brainy isn't open source or publicly available, you can click on the project
names in the list to see its scan results.

------
weavie
How does one go about conducting such audits? Is it just a case of looking at
the code long with an experienced eye to spot potential flaws? Or are there
standard techniques and tools that people follow?

~~~
tptacek
There are a bunch of different approaches.

The simplest and probably the most common is to simply read the code. With
experience, patterns of vulnerabilities pop out at you; also, you get good at
quickly eliminating code that isn't likely to be in the critical path of a
vulnerability, allowing you to focus on the code that is.

Some people start from patterns and work backwards through code looking for
reachability. 10 years ago, you might have done that by sweeping for memcpy's
and working back to inputs. Nowadays you'd probably be looking for
pointer/length math, or allocations and frees.

A primitive automation technique is get the target hooked up to a debugger and
then run a blind fuzzer at it looking for faults. More advanced fuzzers will
track basic block coverage and tune inputs to reach new paths.

If you're really committed to a particular project (like, someone's paying you
to do it, and you have a fair bit of time), you might hoist the code out of
its natural setting and build a test harness for it, so you can fuzz it "in
the abstract" without having to deal with any of its surrounding code. I've
done that for OS work before (you'd be surprised how much of a kernel you can
"port" back to userland, if all you need to do is exercise logic).

Peers of mine have also instrumented virtual machines like QEMU to do this
kind of testing.

Finally, the most modern way to do this kind of work is to generate models for
the code and then use provers to verify things about them. SMT solvers were
all the rage for this a few years ago; my sense is that code proving tools
have gotten more interesting than that since then.

~~~
justincormack
You can already run NetBSD in userland (rump kernel).

~~~
tptacek
Right, I'm not being very precise; you don't necessarily want the whole kernel
(because then you have to model inputs for all the interactions with all the
kernel subsystems), but rather to isolate the one component under test.

------
Palomides
>I stumbled across a PR from 2010, which was briefly saying that PF’s TCP-SYN
entry point could crash the kernel if a special packet was received. Looking
at the PF code, it was clear, after two minutes, where the problem was.

I wonder how often problems like this languish in bug trackers (due to a
shortage of developer availability? flood of low-quality bugs? other
problems?)

~~~
colechristensen
Maybe such things could be solved by having a bug tracker linked to a sort of
CI system where you could upload code/tests/etc to _demonstrate_ the bug in
question

~~~
koolba
That already exists. Simply create a failing test as a separate commit then
have the fix be a subsequent commit.

------
w8rbt
Glad he is sharing his findings with OpenBSD and FreeBSD too. Great work.

~~~
ksec
Since he is paid to work on NetBSD, I wonder if his work on OpenBSD and
FreeBSD will earn him anything. But really glad they are shared among BSD
lands.

Off Topic Questions, is NetBSD still being used in Appliance? Apple AirPort
used to use it as OS, but now it has been discontinued.....

------
liveoneggs
it would be great if FreeBSD could fund some more research/auditing!

------
WindowsFon4life
This is great news. Since they took a beating in the last security findings in
code that was not even enabled by default. Leading to it seeming much more
serious than it was.

------
ape4
More proof that networking should be separated from the kernel.

~~~
yjftsjthsd-h
If we want anybody to buy into it, this needs to not crater performance. Now,
in some cases kernel bypass is actually used to increase performance, so I
have hope; we just need a fast communication method in user space so other
programs can use our new stack. And for adoption, we should ideally be able to
intercept existing network calls (library override?).

...huh, that actually sounds plausible. Have I missed anything?

------
Yuioup
I thought an audit was just analysis but it looks like the author is also
making changes to the code as well.

------
MikkoFinell
Why don't they just write the network stack in Rust? Then we would know it's
secure with no audit required.

~~~
yjftsjthsd-h
If they rewrote it in Rust, we would have reasonable assurance that there were
no memory safety errors. This is not the same thing as secure.

