Where or how do you get a secure embedded TCP/IP stack

[legacy]

and none of them understand human nature.  :-( :-(

yes, understanding human nature is a very difficult and complex task.
See what has just happened here

Anonymous - Wed Oct 24, 2017
Yo men you have no chance. release the doc to those are skillful and retire from the scene, or look over there in the computer room, toothpick looks like it's gonna break in half any minute now.

On Xmas, someone found we had a vulnerability in our PHPBB forum and during a cyber attack it was used to damage the DB, among other things. Since then we are keeping everything segregated for our internal use, with weekly backups etc, and for sure we are not willing to spend more time at sanitizing our PHP interfaces.

We have updated Linux, Apache, and MySQL, and removed all the extra features from PhpBB. We should enforce it on a higher level and spend months at testing the engine for potentially new vulnerabilities, but it's for a hobby, therefore it's not worth with.

Now they are giving us ridiculous threats for releasing documentation we have under Confidential Disclosure Agreements, which of course they can only forget.

I doubted these individuals had ever really existed, now I know they actually exist and the Dorks are actually out of there 

[NorthGuy]

Apart from giants like Google, IBM, Amazon, microsoft, etc,
a normal company does not have the resources to do this.
Besides, you very likely also need ARP, DHCP, firewall, etc.
It's simply too much work for a normal company.

You're kidding? I've seen you posted your software on the forum. So, you can write software. I'm sure if you decide to write a TCP/IP stack, you will be able to do it relatively quickly. The task seems insurmountable to you since you don't know how to approach it, but it's really nothing difficult in TCP protocol and it is very well documented. Common attacks are also documented, so you'll be able to avoid them from the start.

[Marco]

The problem is doing it provably correct, or even doing it provably without buffer overflows when done in C.

[hans]

Getting something to a functional state is at most 10% of the work.

[legacy]

You're kidding? I've seen you posted your software on the forum. So, you can write software. I'm sure if you decide to write a TCP/IP stack, you will be able to do it relatively quickly. The task seems insurmountable to you since you don't know how to approach it, but it's really nothing difficult in TCP protocol and it is very well documented. Common attacks are also documented, so you'll be able to avoid them from the start.

It takes a lot of test cases, which sure it takes a lot of time and effort, but is feasible and it's an all matter of estimating how much time and effort, and this depends on the experience of guys in a testing team who know how to handle these scenarios more efficiently (because it's their job) than a common developer.

This is my professional experience: don't test your own code, ask a testing team to do it, it will be done better, and faster.

[NorthGuy]

The problem is doing it provably correct, or even doing it provably without buffer overflows when done in C.

You mean testing? Why is that a problem? Aside of simulations, you can connect it to a network, send all kinds of raw packets to it and make sure it handles everything correctly. Everything needs testing, how TCP is different?

[legacy]

You mean testing? Why is that a problem? Aside of simulations, you can connect it to a network, send all kinds of raw packets to it and make sure it handles everything correctly. Everything needs testing, how TCP is different?

eh, but it doesn't work this way 

A well-done testing activity done on engineering drafts requires you to stub the code, inject test cases and compare expected results with actual results, this must be done for every function, testing the behavior on both normal working and abnormal conditions.

If this passes, the code escalades to alpha and needs to be retested on the target (when applicable) to see how it reacts to stimulus in the real world.

Otherwise, you just have a shallow testing, which may hide surprises.

For the first step of the software life cycle, see at least what the following software are, and what you to do with them

• CodePurify
• Cantata

p.s.
and I am not talking about the dynamic coverage, which is mandatory in every beta steps for more advanced testing activities.

[NorthGuy]

You mean testing? Why is that a problem? Aside of simulations, you can connect it to a network, send all kinds of raw packets to it and make sure it handles everything correctly. Everything needs testing, how TCP is different?

eh, but it doesn't work this way 

Regardless of how it works, it's the same for TCP as for any other code.

[legacy]

Regardless of how it works, it's the same for TCP as for any other code.

sometimes you are embarrassing, like 200Mhz on a breadboard 

[Marco]

You mean testing?

No, if I did I would have said so.

When you code the stack in Java you know from principle it won't have buffer overflows. To do the same with C is not trivial, testing doesn't help much.

[NorthGuy]

When you code the stack in Java you know from principle it won't have buffer overflows. To do the same with C is not trivial ...

What you're saying sounds like utter non-sense to me. I guess someone may be afraid of buffer overflows and thus destine to program in Java, or worse in Python. I feel sorry for them. But why does it make writing TCP stack any different from writing any other code?

[NorthGuy]

sometimes you are embarrassing, like 200Mhz on a breadboard 

Oh, I actually had some free time, so I wrote some text which describes my 200 MHz breadboard tests for my blog, but I'm now busy with other things, so I had to pause. Writing blogs actually takes more time than I had imagined I'll post the link when I'm done.

[Karel]

The problem is doing it provably correct, or even doing it provably without buffer overflows when done in C.

You mean testing? Why is that a problem? Aside of simulations, you can connect it to a network, send all kinds of raw packets to it and make sure it handles everything correctly. Everything needs testing, how TCP is different?

Ofcourse you are right.
Google, IBM, Amazon, microsoft, etc. are so stupid and/or lazy that it took them many years to write a reasonable safe TCP/IP stack...

[Marco]

What you're saying sounds like utter non-sense to me. I guess someone may be afraid of buffer overflows and thus destine to program in Java, or worse in Python. I feel sorry for them. But why does it make writing TCP stack any different from writing any other code?

It's trivially exposed to attacker constructed inputs and when it's third party there is no security through obscurity.

When you have some proprietary code to take keypad input even if it has an exploitable buffer overflow it's not very likely to be abused (although it has happened with some console games).

[technix]

There is none - for the network stack to be secure it has to be fairly complicated due to all the checks and dynamic handling, and when you need those (as well as cryptography for authentication) the cost of that big a microcontroller start to increase so much that you might as well step up to something running full Linux and it would be a cost cut - a SoM like Raspberry Pi Compute Module or an integrated-DRAM SoC like Allwinner V3s or Microchip ATSAMA5D27C-D1G. With full Linux you get a well tested (since it is used in 99% of the world’s servers) and full functional TCP/IP stack.

[NorthGuy]

Google, IBM, Amazon, microsoft, etc. are so stupid and/or lazy that it took them many years to write a reasonable safe TCP/IP stack...

Companies are not people. They cannot be stupid or clever.

AFAIK, none of these companies ever created TCP/IP stacks (may be except Microsoft). I am not a historian, but I think Microsoft simply used old Unix TCP/IP stack without much modifications. They even used old names for the functions. Microsoft  WinSock API even has select() which is huge contrast to the rest of WinAPI..

The safe TCP/IP stack had already existed long before these companies were created (may be with exception of IBM).

[andersm]

When you code the stack in Java you know from principle it won't have buffer overflows.

Boundary checking is at best a partial solution. You still have an error condition that needs to be handled in a safe manner. Language will never be a solution to security. At best, it can reduce the risk of some types of bugs, at worst it opens up whole new classes of errors. Eg. with Java you add the whole JRE as a target, and it has had its share of vulnerabilities over the years.

There are some formal proofs of the TCP/IP protocol, but I couldn't find if a formally verified implementation exists.

[andersm]

I am not a historian, but I think Microsoft simply used old Unix TCP/IP stack without much modifications. They even used old names for the functions. Microsoft  WinSock API even has select() which is huge contrast to the rest of WinAPI..

I do not think this is correct. The Winsock API is obviously based on the Berkeley sockets API, to make porting easier, but I believe the implementation is their own. In older versions of Windows, some of the utilities (eg. ftp.exe) was based on BSD code, and contained the BSD license strings, but I don't remember ever seeing evidence that the same was true for the stack itself. It's always just been third- or fourth-hand claims.

[NorthGuy]

I do not think this is correct. The Winsock API is obviously based on the Berkeley sockets API, to make porting easier, but I believe the implementation is their own. In older versions of Windows, some of the utilities (eg. ftp.exe) was based on BSD code, and contained the BSD license strings, but I don't remember ever seeing evidence that the same was true for the stack itself. It's always just been third- or fourth-hand claims.

Of course there may be no direct evidence for a closed source product, so it is pointless to discuss, but look at these fragments from Microsoft's winsock.h:

Code: [Select]

* Basic system type definitions, taken from the BSD file sys/types.h.


Code: [Select]

* Structure used in select() call, taken from the BSD file sys/time.h.


Code: [Select]

* Commands for ioctlsocket(),  taken from the BSD file fcntl.h.


Code: [Select]

* Structures returned by network data base library, taken from the
 * BSD file netdb.h.  All addresses are supplied in host order, and
 * returned in network order (suitable for use in system calls).


Code: [Select]

* Constants and structures defined by the internet system,
 * Per RFC 790, September 1981, taken from the BSD file netinet/in.h.


Code: [Select]

* Definitions related to sockets: types, address families, options,
 * taken from the BSD file sys/socket.h.


[Marco]

At best, it can reduce the risk of some types of bugs, at worst it opens up whole new classes of errors. Eg. with Java you add the whole JRE as a target, and it has had its share of vulnerabilities over the years.

Sandbox escapes are only relevant if you allow arbitrary code execution within it. Those exploits are irrelevant to using Java as a programming language.

There are no classes of bugs which are as exploitable as buffer overflows and use after free. The only thing which gets close in economic damage is SQL injection and cross site scripting. Nothing Java has gets remotely close.

There are some formal proofs of the TCP/IP protocol, but I couldn't find if a formally verified implementation exists.

As I said twice already, HCC embedded.

[andersm]

Of course there may be no direct evidence for a closed source product, so it is pointless to discuss, but look at these fragments from Microsoft's winsock.h

All networking stacks that provide a Berkeley socket interface will have the same structures and types, since they're part of the API. Copying them from an existing source instead of typing them in yourself just makes sense.

[andersm]

There are no classes of bugs which are as exploitable as buffer overflows and use after free.

But they're not the only bugs. The idea that you're safe just because you're using Java died a well-deserved death in the 90s.

As I said twice already, HCC embedded.

In their brochures they're talking about using static analysis tools, but couldn't find any reference to any correctness proofs. If they actually have one I would have expected them to make a bit more noise about it.

[Marco]

The idea that you're safe just because you're using Java died a well-deserved death in the 90s.

Don't let perfect be the enemy of good ... like much of the IT industry has done for decades.

[legacy]

something running full Linux and it would be a cost cut

yup, or BSD, not necessary OpenBSD, but it would be an option.

[legacy]

The only thing which gets close in economic damage is SQL injection and cross site scripting

The risk is real. On our DownTheBunker website, we have recently experimented in person on a cyber attack which has seriously damaged the DB, and by investigating on the causes, we have then found open vulnerabilities exposed by the PHP code