After a discussion with some colleagues, we have some concerns:
Has anyone ever audited zerotier?
Can you explain (e.g. based on programming methodology) why you think it's secure? E.g. I have the impression that you don't use a lot of networking or crypto libraries and instead provide implementations which you have partially copy-pasted (from reputable sources at the time, I will admit that), which results in longer term maintenance and security problems. All in all, it seems to be optimized for speed (presumably to look good in benchmarks), not security (other than in terms of buzzwords).
Have you ever fuzzed this system?
You could potentially apply here: https://github.com/google/oss-fuzz.
Has the daemon ever crashed after 1.0?
What's the worst thing that will happen when the daemon is compromised?
Why do you think you haven't made the same mistakes as OpenSSL?
I think the core idea is great, but I personally have some concerns over the implementation. I would love to see strong answers for the above to remove these doubts.
coretemp
All 4 comments
Has anyone ever audited ZeroTIer?
We've had some informal audits by customers but no formal audits. Product has been around for years and is OSS and we've never had a critical issue (remote access, serious denial of service, etc.).
Have you ever fuzzed this system?
We've fuzzed parts of it: packet decoding and the Dictionary.hpp parser come to mind. We've not done fuzzing across the entire API. Network fuzzing would be of limited usefulness because all packets are authenticated.
Has the daemon ever crashed after 1.0?
That's kind of an odd question. In development it has of course, but I assume you mean release versions. We have had issues related to threading and OS compatibility, but as far as I know we have not had a buffer overflow or other exploitable issue. Overall the daemon is extremely stable and we have systems in production that have been running it for over a year without restarts.
What's the worst thing that will happen when the daemon is compromised?
(1) Compromise of network traffic and theft of secret keys.
(2) Unauthorized access to the network -- of course compromise of the device itself gives you this regardless of whether ZeroTIer itself is compromised.
Why do you think you haven't made the same mistakes as OpenSSL?
That's too broad a question. From what I've seen the original OpenSSL code base was a mess and desperately in need of cleanup. It had many issues.
We built ZeroTier from the ground up using secure coding techniques everywhere we could. First and foremost we use bounds checked structures when parsing anything we get over the network. See Buffer.hpp. Dangerous areas of the code are limited in scope and where possible have been fuzzed and extensively profiled.
Other than that we can't make absolute guarantees... but nobody can. There are people who will be honest and tell you their software could have bugs and there are liars who will claim it's "perfectly secure" etc.
adamierymenko
on 21 Jul 2018
Thanks for taking the time to answer my questions.
I am not trying to start an argument, but https://www.adacore.com/academia/projects/ironsides-secure-dns-server goes quite far regarding security and guarantees. Similarly, DARPA has held security events with code implemented in Coq, which was essentially invulnerable to attack (first time that happened). I am not saying you should rewrite everything in Coq, but it is technically feasible to do so today.
This is a non-technical article on the subject: https://www.wired.com/2016/09/computer-scientists-close-perfect-hack-proof-code/ (I am sure you can find the academic papers when interested). When you actually want to move the needle regarding security, that's the way to go (I believe senior DARPA leadership has been convinced about this).
I also have the impression that you aren't really using the standard library a lot.
E.g. bounds checking can be done with std::basic_string::at too and some of your loops can also be rewritten to use the standard library.
Similarly, why don't you use https://nacl.cr.yp.to instead of rolling your own?
coretemp
on 23 Jul 2018
I can also recommend libsodium made by @jedisct1 .
meguroyama
on 25 Aug 2018
@coretemp Did you do any audit or assessment? I am curious to know what your team decided?
ort163
on 19 Feb 2019
Related issues
MaskRay
路
4Comments
tim77
路
4Comments
Fastidious
路
5Comments
AlexisTM
路
4Comments
bstin
路
3Comments
Most helpful comment
We've had some informal audits by customers but no formal audits. Product has been around for years and is OSS and we've never had a critical issue (remote access, serious denial of service, etc.).
We've fuzzed parts of it: packet decoding and the Dictionary.hpp parser come to mind. We've not done fuzzing across the entire API. Network fuzzing would be of limited usefulness because all packets are authenticated.
That's kind of an odd question. In development it has of course, but I assume you mean release versions. We have had issues related to threading and OS compatibility, but as far as I know we have not had a buffer overflow or other exploitable issue. Overall the daemon is extremely stable and we have systems in production that have been running it for over a year without restarts.
(1) Compromise of network traffic and theft of secret keys.
(2) Unauthorized access to the network -- of course compromise of the device itself gives you this regardless of whether ZeroTIer itself is compromised.
That's too broad a question. From what I've seen the original OpenSSL code base was a mess and desperately in need of cleanup. It had many issues.
We built ZeroTier from the ground up using secure coding techniques everywhere we could. First and foremost we use bounds checked structures when parsing anything we get over the network. See Buffer.hpp. Dangerous areas of the code are limited in scope and where possible have been fuzzed and extensively profiled.
Other than that we can't make absolute guarantees... but nobody can. There are people who will be honest and tell you their software could have bugs and there are liars who will claim it's "perfectly secure" etc.