Schneier on Security

Clive Robinson • August 14, 2014 5:01 AM

Whilst I agree in general with the idea, it has it’s own perception gap that will cause problems.

Ask yourself where should you realy do security or error checking, right up at the front of the programe (left side) or where it actually matters in the programe (right side)?

Logicaly you put it where it is actually required which is way over to the right in the actual program logic, bound as tightly as possible to the part of the logic where it is needed. Thus the logic becomes self protecting and as highly specific as required, which means you can use tight criteria and strong checking withou fear or favour. Which makes the priority “reject over accept”, as well as making the code very much less suseptable to changes in other parts of the code.

However in practice this is not what happens, the mantras of code reuse refactoring and coder efficiency says make it general and move it as far to the left as possible so exception handeling code is minimised or even eliminated. The problem with this is it opens up lots of security holes, I could go through some of them but the list is longer than my beard (even in near zero point print 😉

But two issues crop up over and over again with left side checking,

Firstly even tiny changes effect many functions, trying to check them all is a fools errend at best.

Secondly as technology improves code moves, the classic example being the move of server side code into web browsers, what shifted was the left side code with most if not all of the error and security checking… opps, it did not take long for attackers to exploit that little faux pas. Whilst this now seems obvious, it actually still goes on as code gets moved from pilot project to initial production and numerous up scalling steps there after.

Much time and effort becomes wasted with left side error and security checking and it realy should be treated as very poor programing practice.

But there is an issue with right side checking, which is what to do with failures etc that get caught deep inside the code do you just drop them at that point, abort the program, or run it backwards to the left, such that error reporting and error correction can work in the way users, administrators and others would expect.

Obviously the last option is preferrable where possible, and that is the problem, programers will throw their hands in the air and say it’s not possible “no way no how” which of course is a lie.

Doing it requires discipline and building in from day zero, all interfaces need to be bidirectional not just in control information but data as well. This alows such problems as hardware errors and overloads to be dealt with efficiently in multi-tier and distributed systems, and has been around for many years in one form or another such as journaling file systems and high availability database systems.

This however brings up an issue that few people are aware of or even comprehend which is security also needs to be bi-directional otherwise a down stream attacker can use techniques to force false entries upstream that then get treated as security checked and go down stream via a different path, that is not open to an attacker due to normal security checking.

The problem with doing all of this on the right side is that it means a lot more code has to be written, and programers have to get their heads around proper security and error checking in both directions, non of which is going to make short term management happy. However forward thinking managment should at the least see it as an acceptable quality process and further see the down stream savings in maintenance and upscaling costs.

Clive Robinson • August 14, 2014 6:21 AM

@ Gerard von Vooren,

With regards languages, most are actually unsuitable, unless they can make and handle multiple value returns from a subroutine in a standard and safe way. Which has further implications such as null values that cannot be treated as valid data etc and what to do if a value is either unexpected, missing or out of range.

Further is the issue of having comms / interfaces with both data and control channels that are both bi-directional, this has six way synchronisation issues that need to be correctly addressed. Most current OSs do not do this or do it badly, so that needs to be addressed as well.

Thus you would tend to start looking at a minimum of RTOS systems with the appropriate languages (ranging up to highly parallel systems from the hardware up).

Judging by what happens with threads currently many programers are nowhere near ready to make this sort of transition, which in of it’s self is just a halfway house to what we should be doing with highly parallel systems (which is where the future of computing is going to be).