This is a perfect illustration of the point I made in the previous entry: Most kiddie researchers who find security bugs in code cannot themselves write secure code. A buffer overflow was discovered in Apache's processing of .htpasswd files and the fix posted to bugtraq contained another security bug. (Pointed out by Michael Howard).
DJB is teaching a class on UNIX security holes this fall and of course he's taking plenty of stabs at sendmail, using old bugs as a demonstration of what not to do. The first set of slides also takes a stab at the design of Windows.
The class does exactly what it says on the tin: 'UNIX security holes' -- it teaches students to find and exploit security holes, not to write secure software. It would help a lot more if students went through a year of solving software problems which were then reviewed for bugs.
Michael Howard said to go look at Aaron Margosis's weblog so I did. It's called The Non-Admin blog of all things. Those of us who hate knowing we can wipe out system32.dll by mistake will find a good deal of tips to make our Windows lives easier.
I started writing a Subversion security document and posted it to the Subversion developer list. Unfortunately, I got a few facts wrong in the first draft which was not appreciated nor was my style of writing. The discussion quickly degraded into nagging about who took part in what at various points in the process and my interest in improving Subversion was finally killed completely when someone said I was part of the problem.
I am amazed at the number of developers in the world who still do not appear to comprehend any sort of defensive development. If Microsoft continue their current efforts at developer education and security-driven development methods, they are going to have one of the most resilient platforms in two years time.
Oh, if any of you are running public Apache-based Subversion repositories, let me know. I need some motivation to finish the Apache 2 part of the guide.
I have a fever. It looks like I will not be in work tomorrow.
I got new hardware up and running yesterday. It is faster than priceless, but there is still room for improvement. I suspect I cannot get much faster without giving up on my 'silent hardware' requirement.
builder$ cd /usr/src && time make build [..] 23303.71s real 17965.98s user 4159.59s system
I've got cvsyncd running on marvel, meaning local machines
can get various sources easily. rwhod is pretty handy on a
trusted network. Symon and distcc are next.
marvel$ ruptime builder up 10:00, 1 user, load 0.12, 0.09, 0.08 marvel up 96+19:32, 1 user, load 0.08, 0.10, 0.08
I am quoted in the new book IT-sikkerhed ifølge eksperterne ("Information security according to the experts") as urging people to understand risks and threats as opposed to just installing random software tools to protect themselves. (p. 84-87).
Thankfully, I was referred to as a 'security specialist', not a 'security expert.'
I wonder if my employer will start to listen now that I am suddenly quoted in the printed press. Hope is a good thing. Maybe the best of things.
I need faster hardware.
priceless$ cd /usr/src && time make build [..] 30741.36s real 11625.20s user 3166.62s system
Today I composed a list of the projects and activities I have worked on or otherwise been involved with in the time I have worked for my current employer. The total count is ten, which isn't unusual, as I am only supposed to work on larger projects and not take part in day to day operations.
Of those ten projects, only two were completed in a meaningful way. One involves just me, really and the other was not implemented with the level of thought I would have desired, but there you go. The remaining eight were left to die because of poor mgmt support/follow-up, poor specification, or simply implemented in a manner that only wasted resources without providing any real security improvement.
If you have been following along with the show that is my diary, you will know that I am not cheap labour. Why would someone want to hire me and then not listen to my observations? The point of my (professional) existance escapes me. By no stretch of my imagination would I expect that people blindly implement every little suggestion I make - but I would certainly expect careful consideration to be a given, and reasons for going along (or not going along) with the suggestion to be put down on paper.
Another thought: On several occasions, while making recommendations, I have been asked to provide documentation that someone else also recommends the same particular approach. This baffles me. What is the line of thinking here? "He may be incompetent/totally wrong, so we will get him to present proof that at least one other incompetent/totally wrong person shares his point of view"?
This was the computer-related highlight of my day:
22:48 <dogs> A byte walks into a bar and orders a pint. Bartender asks "What's
wrong ?", the byte replies "Parity error". "Ahh", said the barman,
"I thought you looked a bit off".
Daily Rush sucks for two reasons. One:
$ ftp http://files.dailyrush.dk/demos/tribesv_mpdemo.exe Trying 217.116.227.202... Requesting http://files.dailyrush.dk/demos/tribesv_mpdemo.exe 73% |************************************ | 348 MB 28:19 Read short file.
And two: They continue to misinform their users about the reason Tiscali decided to route traffic via their London peers rather than the DIX.