The Electronic Mayhem ended in 3rd place in Cipher 5 CTF
Submitted by Yves Younan on Sun, 2009-07-12 23:53Our team, The Electronic Mayhem has ended in 3rd place in the Cipher 5 Capture the Flag. Even though the CTF focussed heavily on python (which was not our strongest point), we were able to get some exploits going and were able to end in third place.
The Electronic Mayhem wins the Darmstadt Open 2008 CTF
Submitted by Yves Younan on Fri, 2008-09-12 21:58The DistriNet CTF team, called The Electronic Mayhem, ended in first place of 17 teams during the Darmstadt Open 2008 Capture the Flag. It was a challenging contest that remained exciting till the end, where our team managed to stay just ahead of teamSparta (of mwcollect.org) and ENOFLAG (from the University of Berlin) who took second and third place respectively. More details on http://ctf.sec.informatik.tu-darmstadt.de/daopen08/final_results/
Fourth place in the Cipher CTF
Submitted by Yves Younan on Thu, 2008-08-14 21:46Efficient countermeasures for software vulnerabilities due to memory management errors
Submitted by Yves Younan on Sat, 2008-08-09 02:23On this page you will find my PhD thesis:
Efficient countermeasures for software vulnerabilities due to memory management errors
Author: Yves Younan
Published as: PhD Thesis, Katholieke Universiteit Leuven
ISBN: 978-90-5682-936-0
Date: May 2008
Abstract:
Despite many years of research and large investments by companies, the development of secure software is still a significant problem. This is evidenced by the steady increase in vulnerabilities that are reported year by year. Fast spreading worms like the Code Red worm, which caused an estimated worldwide economic loss of $2.62 billion, will often exploit implementation errors in programs to spread rapidly.
Dnmalloc 1.0
Submitted by Yves Younan on Sun, 2008-07-06 15:59Dnmalloc 1.0 has been released!
Thanks to Rainer Wichmann for bugfixing the code to make it release quality. He will also be shipping dnmalloc 1.0 with the next version of Samhain. He'll also be contributing possible future enhancements to dnmalloc and as such is now an official developer.
To facilitate this, we've set up an svn server: http://svn.fort-knox.org/code/dnmalloc/
You can check out the code from this server by doing:
svn co http://svn.fort-knox.org/code/dnmalloc/
Changes by Rainer since beta 5:
Compiler warnings fixed
Define REALLOC_ZERO_BYTES_FREES because it's what GNU libc does
(and what the standard says)
Phd Defense: May 8th 2008
Submitted by Yves Younan on Mon, 2008-05-05 23:29I would like to invite you to attend the public defense of my doctoral dissertation entitled:
"Efficient countermeasures for software vulnerabilities due to memory management errors", promoted by Prof. Dr. ir. W. Joosen and Prof. Dr. ir. F. Piessens.
The defense will take place on May 8th at 17h00 in the auditorium of the Department of Computer Science of the Katholieke Unversiteit Leuven:
Room 200A 00.225
Celestijnenlaan 200A
3001 Heverlee
A short description of how to get there can be found at:
http://www.cs.kuleuven.be/cs/algemene_info/plan/images/grondplancw.jpg
After the defense, there will be a small reception.
Abstract:
The fifth Belhack meeting
Submitted by Yves Younan on Mon, 2007-08-13 00:21The next few belhacks are being organised by Thomas Heyman since I'm in the US for a few months.
We took the opportunity to change the format a bit, we're now allowing people to attend even if they don't speak. We do, however, expect some level of participation if you attend.
The CFP is out at http://wiki.belhack.com/index.php/CFP5
Third place in the USF CTF
Submitted by Yves Younan on Tue, 2007-04-24 13:52The University of South Florida held a CTF on Friday, April 20th. Our team, The Electronic Mayhem came in third out of a total of 20 teams . We were only 23 points from the team in 2nd place.
Interesting feature: the 59 top influencers in IT security
Submitted by Yves Younan on Fri, 2007-03-16 02:25IT security has an interesting feature article, even though I think they're slightly premature in naming the top influencers for 2007 in March already, it is an interesting read.
See http://www.itsecurity.com/features/top-59-influencers-itsecurity-031407/
Update:
Apparently some people don't like being on IT security's list: http://www.matasano.com/log/723/take-me-off-your-list/
While I did think the list was interesting (I picked up some blogs I didn't know about), he raises a valid point that some people (like Michael Howard) are definitely missing.
Belhack.com: Belgian Hacker Community
Submitted by Yves Younan on Thu, 2007-03-15 22:59If you're a Belgian and reading this, chances are I've already emailed you about this, so you can stop reading now :)
However on the off chance, that I forgot to mail you here goes:
We've started up a project called belhack.com, which is a short for "Belgian Hacker Community". The idea of this community is to have monthly meetings where people interested in computer security talk about different topics. The only requirement to attend is that you present something (5-10 minutes) which the other members may be interested in.
If you're interested, check out http://www.belhack.com
Two papers up
Submitted by Yves Younan on Wed, 2006-12-06 18:11A while ago I mentioned that two of my papers were accepted at ICICS 2006 and ACSAC 2006 respectively.
Since I'm currently at ICICS and going to ACSAC next week, I've finally put those papers online.
The first paper is titled Efficient protection against heap-based buffer overflows without resorting to magic and will be presented at ICICS today.
The second paper is titled Extended protection against stack smashing attacks without performance loss and will be presented at ACSAC on December 14th.
Comments for either paper are, as usual, welcome
Extended protection against stack smashing attacks without performance loss
Submitted by Yves Younan on Wed, 2006-12-06 18:03Authors: Yves Younan, Davide Pozza, Frank Piessens and Wouter Joosen
Published in: Proceedings of the Twenty-Second Annual Computer Security Applications Conference (ACSAC 2006), Miami Beach, Florida, U.S.A., IEEE, IEEE Press
Date: December 2006
Abstract:
In this paper we present an efficient countermeasure against stack smashing attacks. Our countermeasure does not rely on secret values (such as canaries) and protects against attacks that are not addressed by state-of-the-art countermeasures. Our technique splits the standard stack into multiple stacks. The allocation of data types to one of the stacks is based on the chances that a specific data element is either a target of attacks and/or an attack vector. We have implemented our solution in a C-compiler for Linux. The evaluation
Efficient protection against heap-based buffer overflows without resorting to magic
Submitted by Yves Younan on Wed, 2006-12-06 17:53Authors: Yves Younan, Wouter Joosen, and Frank Piessens
Published in: Lecture Notes in Computer Science Volume 4307/2006: Proceedings of the Eighth International Conference on Information and Communication Security (ICICS 2006), Raleigh, North Carolina, U.S.A., Springer-Verlag.
Date: December 2006
Abstract:
Bugs in dynamic memory management, including for instance heap-based buffer overflows and dangling pointers, are an important source of vulnerabilities in C and C++. Overwriting the management information of the memory allocation library is often a source
Interview with Marcus Ranum in IEEE Security and Privacy
Submitted by Yves Younan on Tue, 2006-11-07 02:28The latest issue of IEEE Security and Privacy features an interview (only accessable if you subscribe to IEEE) with Marcus Ranum (the firewall guy). He makes some specific claims in it which I strongly disagree with.
First, he criticizes Microsoft for constantly enhancing their products with new features, which of course result in new security vulnerabilities. He compares this to a website which he made a long time ago, which was really small. The result of the website? Well it's still up today and they never needed to patch it. Talk about bad analogies. Does anyone remember Windows 3.1.1? I do. It sucked. Let's say for the sake of argument that Windows 3.1.1 was hypersecure, would you be willing to trade it for Windows XP (or even Windows ME or whatever other Microsoft security disaster)? I know I wouldn't (which is why I use Mac OS X: it may be terribly insecure, but I like using it). Security is not a goal, security is a non-functional requirement which is very important. More important, however, is that the software has functionality that users need. Requirements also change over time: the website he made may be secure, but it was obviously for a company that is not evolving rapidly. When Office was first released, you couldn't use it to create web pages and saving everything as a Word document was fine. Nowadays people expect to be able to save their files as html or pdf (does Word support this natively these days?). New requirements mean new features which mean new security vulnerabilities. There's no getting around that, unless you are happy with stone age systems. For people that have reliability as an absolute requirement, this may be acceptable. For the rest of us it is not.
hack.lu review
Submitted by Yves Younan on Sun, 2006-10-22 23:27I attended hack.lu from thursday evening to saturday afternoon.
It was an interesting conference: mainly because of the attendees rather than the speakers. However, Wietse Venema's talk on Software Engineering Security was very interesting though. He talked about a file wipe program which was badly broken although the code looked reasonably correct. He then demonstrated how a fix was proposed, and how that did not do much either. The main reason that it was broken was because of assumptions the authors (and fixers) made about what the operating system/hardware would do versus how it did things in reality.
Sandip Chaudhari talked about a way to exploit memory allocators by overwriting the memory management information and then abusing a following malloc call rather than a free call. It was a pity that he focussed his research on AIX and Solaris rather than more modern operating systems. I was happy to learn that our malloc (dnmalloc) was not vulnerable to this attack.
