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] [day] [month] [year] [list]
From: brett at hutley.net (Brett Hutley)
Subject: Microsoft Cries Wolf ( again )

> > Along these lines, if the C programming language had a proper 
> > string data type from day one, buffer overflows would be much 
> > less common today.  

Ha! Yeah right - and how would your operating system perform doing
boundary checks on every string operation???

Thus trumpeted Mike Fratto on Tue, Jul 01, 2003 at 12:55:51PM -0400
> Not to get into a religious argument over this, but if programmers did
> proper data scrubbing and bounds checking regardless of the language, there
> wouldn't be much of a problem either. Granted, I am not uber programmer (I
> have hacked together proggies of a couple of thousand lines for my own use
> and I am sure there were lots of problems in them) but even being self
> taught, I learned to do data scrubbing and bounds checking just for
> reliability. I have to think it is taught in programming 101.

Yeah, well I AM a professional programmer - have been for over 15 years.
I always get a bit riled when I see people who have only coded up "Hello
World" applications say this kind of thing (and there seem to be a lot of
them involved in security). Real world programs are big complex beasties,
potentially involving threads, sockets, complex GUI elements and the
like. Try looking through 100k lines of code in a complex multi-threaded
app that you know segfaults randomly when running on multi-processor
machines to find the unprotected counter (an atomic operation on one
processor, but not on two). The program I am working on at the moment
is fully distributed because it needs to process years of data, the
correlation matrices are encoded in eigenvectors because it's the only
way we can fit them in memory, we have large gigabyte-sized files that
are chunked into memory on demand and the processing is distributed among
8 different types of servers to try and max out processors, hard drive
and network throughput. I KNOW that there are security problems in there,
although most of the programmers on the project are extremely experienced,
and we bounds check the code religously. To take one example; the socket
connections pass the objects as an unprotected binary data stream. If
we encrypted the stream we wouldn't be able to get the throughput. To
take another example; we don't use the C++ std::string class - even
though it's "a proper string data type" - why? because the overhead of
the heap allocations on string construction make the program too slow.
As a result we have to deal with a far greater likelyhood of a buffer
overflow. But this is the real world! And the nature of coding real
world applications is that we have to make compromises.

Understanding the techniques that security folks use to compromise
programs is important. But given that 60-80% of large programming projects
are going to fail BEFORE the question of poor security even comes up,
I'll take a programmer with a proven track record of getting a program
written even if they haven't had any security training (and I can't get
enough of those programmers so if you know any, let me know and I'll
hire them).

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

I'll get a bunch of monkeys, dress 'em up, and make 'em reenact the Civil
War!  Heh, heh, heh!

		-- Homer Simpson
		   Homer the Great

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ