full-disclosure - Coding securely, was Linux (in)security

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3FA0ABD5.5090501@hutley.net>
From: brett at hutley.net (Brett Hutley)
Subject: Coding securely, was Linux (in)security

Steve Wray wrote:

*snip*
> I think that most programmers approach programming, mentally if not
> practically, from the silicon upwards. They are not thinking so much 
> about the logical structure of their programs, but of the effect of 
> the program on the hardware that it runs on; they are viewing the
> program/computer something like a 'clockwork' machine and they are
> arranging the cogs and gears and things. This is just me guessing,
> I can't see inside other peoples heads. The approach I saw in 
> functional languages was a linguistic approach; the program is
> a set of sentences in a formal language and one can use the tried
> and tested methods of algebra and formal logic to reason about a
> program and (importantly) to *calculate* program components from 
> specifications.

These days I try and create programmatic constructs to match the 
linguistic way I think about the problem in my head. With OO-style 
languages like C++ or Java, some linguistic constructs come out as 
objects, others as methods.

At some point in most programs you need to deal with messy stuff like 
GUI's/user input or file parsing, etc. Then the bug of programming 
smacks into the windscreen of dealing with the hardware/software 
environment and you need to cope with all kinds of messy API's and error 
conditions. The next thing you know, the users have redefined their 
requirements, and all your nice programming abstractions are now 
completely obsolete *sigh*. That's one of the benefits of design 
patterns - they're a good source of abstractions that are flexible and 
long-lived.

I don't necessarily think that secure programming is *hard*, but it does 
take quite a bit of knowledge. Buffer overflows are only one issue 
against the larger backdrop of input validation. Having a good 
understanding of crypto is becoming more and more important... and with 
it being able to use a library like openssl. There's priviledge 
seperation, and temporary file issues. There's SSPI on Windows and 
Kerberos on Unix.... the list goes on and on. Fortunately there are some 
good books that have come out in the last few years that provide a good 
overview of sources of vulnerabilities and techniques for dealing with 
them. I quite like "Secure Programming Cookbook for C and C++" by Matt 
Messier and John Viega. These guys have started a website at 
http://www.secureprogramming.com/ .

Cheers, Brett
-- 
Brett Hutley [MAppFin,CISSP,SANS GCIH]
mailto:brett@...ley.net
http://hutley.net/brett