martes, 26 de abril de 2011
Teaching exploit development
Giving a training is one of the hardest thing you will ever experience in a researcher's life (and one of the most rewarding).
Over the 5 days we spent last week giving the Master Class, there were months spent working on the material, preparing exercises, etc.
My first thought when i did my first training back in 2004, was that it was simple. I completely master the subject i was teaching and the slide deck was pretty solid. But that was just one part of the deal, communicating the knowledge is hard and brain consuming. It's not just "explaining" a subject, but rather transferring the knowledge in such a way that is exciting, mantain the attention of the class for 8 hours a day and it's progressive.
The composition of the class is probably one of the hardest challenge. They are generally very heterogeneous, from super skilled people that should be with you teaching the class to people that are completely new to the subject. I always tell the story of my experience in Japan, where the first day I make everyone introduce themselves and tell me their experience with the heap, two out of the twenty students have no idea what the heap was, and in fact, their expertise on security was very physical: They work installing security doors.
It's really complex to maintain a balance on a class and make everyone happy, you need to be prepare with a series of exercises and even that won't starve the most hungry for knowledge, whether at the same time you need to have simple exercises and good analogies for the new ones.
The classes on exploitation are a subject by their own. An exploit is something that should not be happening on that machine, you have the whole system against you and now you are not only teaching it but helping 34 people at the same time having all kind of problems. And the worst part, you have 30 seconds to sit on his machine and understand every step of their logic to help them out.
For all of those reasons, is why we try to teach methodology over specific exploitation techniques. Bug Class die, primitive don't. And methodology have a lot to do with primitives, whether is messaging the heap layout to craft a deterministic heap or getting a infoleak out of use-after-free.
If you attend a class, and you think that you are only learning how to use a tool, pack your stuff because you just lost. You lost for one of the two reasons: They are actually just teaching you how to use a tool and nothing more or you didn't understood the concept of the class at ALL.
Tools need to be learned to understand the methodology, not because people randomly want to coopt you on the army of users, but rather because they are providing the tools to move from that point one (Of course, they are classes just focus on tools, try to avoid them). Imagine teaching a class of 34 people with completely different backgrounds about SMT Solvers and symbol execution, using SMT-lib language (lisp alike language) or leaving by themselves and the debugger of choice the hooking of very specific functions to obtain some information (You will be have people using from windbg to the most obscure debugging library, and you will have to support them and actively help them with their mistakes).
I want to share just one last anecdote, that summarize the blog post. We were working on an use-after-free exercise the second day of the class, and i just explained a type of script they had to write to hook on specific functions on mshtml.dll to dynamically find softmemleak on Elements properties. Since we were running out of time, I asked the student what they would prefer: Continue working on exploiting the bug or write the script? And Halvar answered cleverly as he usually does: "What's the difference?"