full-disclosure - automated vulnerability testing

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20031129020812.TMWT132452.fep01-mail.bloor.is.net.cable.rogers.com@BillDell>
From: full-disclosure at royds.net (Bill Royds)
Subject: automated vulnerability testing

If you are truly interested in security, you won't use C as the programming
language. It is security unfriendly by design (so it can get closer to the
actual box for efficiency's sake. So what you want to build is a checker
that ensures that the code does not use 
Pointers or pointer arithmetic, C strings, C arrays or C I/O. Only C or
languages that use C libraries have a problem with buffer overflow, format
errors, unallocated (or already freed) pointers and routines returning
incorrect types. 
  Most other languages prevent these as part of their semantics or syntax.
Your checker would need to check that all functions and the calls to them
match arguments as to type, bounds (including string sizes and malloc
space), that pointers are never used before they are allocated or after they
are freed.
  Most of these are situations similar to the halting problem on a Turing
machine so you are unlikely to get an error free checker. But if your
checker complains about all the possible security holes, it will complain
about nearly every construct used within C programs.

-----Original Message-----
From: full-disclosure-admin@...ts.netsys.com
[mailto:full-disclosure-admin@...ts.netsys.com] On Behalf Of
fulldisclosure@...edomnames.co.uk
Sent: November 28, 2003 2:56 PM
To: full-disclosure@...ts.netsys.com
Subject: [Full-Disclosure] automated vulnerability testing

Hey guys,

please excuse me for bringing this topic up again, but i was kinda
disappointed
with the feedback from before...

i'd like some input from the programming community regarding thoughts on
static
vulnerability analysis, not specifically on the products that are already
out
there (kinda limited imho) but rather from a design perspective.
im interested in the kinds of functionality that is required, interface
design,
configuration issues (saved configs etc..) and most importantly the types of
vulnerabilities people would be interested in scanning for.

If i could get some positive feedback it'd be much appreciated.

-DC 

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html