On 2017-05-19 18:02, Bob Sneidar via use-livecode wrote:
I don't think it's a matter of programming standards. The methods used
to exploit systems are almost always something you could never have
guessed. Flaws in code can be extremeny difficult to see, as was the
case in the SSL Heartbleed bug. None of the devs saw the bug when it
was approved for merging. Seeing what it was and what it ought to have
been would be like seeing a needle in a haystack. I have thought for
some time that it is the nature of digital information and our human
minds incapacity to comprehend it in its real form that makes it
nearly impossible to produce "unhackable" code.
I'm not sure this is correct - and it is important that we don't 'lull
ourselves into a false sense of security' by assuming that 'oh we could
never have guessed that'.
The reality is that whilst exploiting a vulnerability in general is
REALLY HARD (seriously, when I say REALLY HARD, I mean REALLY REALLY
REALLY HARD and this is why you only tend to see exploits in things
which have a very large reward for making that exploit - hackers have to
consider ROI too!) - all they need is a vulnerability in the first
place.
Eliminate the chance for vulnerabilities and you eliminate the
possibility of exploits. Of course complete elimination is the ideal,
but generally if you minimise the chance of introducing a vulnerability
to the absolute minimum and you hugely reduce the chance of an exploit
appearing (because finding vulnerabilities to exploit becomes much much
harder).
Simplifying matters a bit, you can pretty much divide vulnerabilities
into two classes:
1) vulnerabilities introduced because of how something is written
2) vulnerabilities introduced because of how something is done
The latter class (2), I will concede are much harder to spot. So called
'information leakage' is a good example of (2) - this is where the
method you use to do something causes 'secrets' to leak into an
accessible channel. The thing is that such leakage can be caused by
stuff the processor does (unreset registers in a call to a critical
function, sideline data accessible due to the way HyperThreads are
implemented in processor cores etc.). This is of critical concern in
security stacks (such as SSL and strong encryption implementations) and
is why the universal advice given is: never implement such things
yourself - use a library which has the involvement of cryptography and
security experts or employ such a person to do it for you.
The former class (1) essentially all boil down to mistakes in coding
which mean that a suitably motivated hacker can use the mistake to
execute arbitrary code which they have written - one of the biggest
classes of these is 'buffer overruns':
int main(int argc, char *argv[])
{
if (argc != 2)
return 0;
char t_buffer[32];
sprintf(t_buffer, "Argument 1: %s", argv[1]);
fprintf(stderr, "%s\n", t_buffer)
}
Here I have a chance of being able to construct a string passed as a
command line argument to my program which could execute arbitrary code
encoded in the string I passed in - because I am potentially able to
overwrite the stack at critical points to execute something that was not
intended.
Another class of (1) is failure to sanitize inputs:
int main(int argc, char *argv[])
{
if (argc != 2)
return 0;
char t_buffer[1024];
snprintf(t_buffer, sizeof(t_buffer), "DELETE %s FROM
MyImportantDatabase", argv[1]);
RunSQL(t_buffer); // Mythical call for illustration only
}
Here I've constructed an SQL query by inserting an unescaped string
directly into an SQL statement that I execute. With this I can do
anything to the database I like - just by using ';'.
I'd put my neck out and say that all vulnerabilities in case (1) can be
prevented by strict programming standards and review (or better) using a
language which doesn't let you make those kinds of mistakes in the first
place.
So, in short, I'd perhaps suggest that all exploits we see are caused by
one of two things:
(1) Using tools which are too low-level for the job at hand, or people
using tools which they are not experienced enough to use fully and
absolutely correctly.
(2) Writing code to do a task when you do not have enough
domain-specific knowledge to do it correctly.
Just my two pence :)
Warmest Regards,
Mark.
--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
