C++ supports developers in object-orientated programming and removes from the developer the responsibility of dealing with many object-oriented programming (OOP) paradigm problems. But these problems do not magically disappear. Rather it is the compiler that aims to provide a solution to many of the complexities that arise from C++ objects, virtual methods, inheritance etc. At its best the solution is almost transparent for the developers. But beware of assuming or relying on ‘under-the-hood’ behavior. This is what I want to share in this post – some aspects of how compilers deal with C++ objects, virtual methods, inheritance, etc. At the end I want to describe a real-world problem that I analyzed recently, which I called a “pointer casting vulnerability”.
I had a pleasure to give a talk at the Confidence 2013 conference. This year conference was in Krakow (28-29th of May). The first CONFidence conference was organized in 2005 and from the beginning became one of the biggest security event in the Europe. Each year many speakers from all around the world attend to the conference. As you can realize schedule of the conference usually keeps high technical standards.
CONFidence is an annual IT security conference that will take place on 28-29th May, 2013 in Krakow. This is one of the biggest and most valuable conference in Central and East Europe. This event is famous not only from the good quality of presentations, but also (maybe most of all) from the great atmosphere of the conference itself and the after party
A lot of great speakers will attend to the conference this year. Details can be found here.
At the beginning I want to inform all my blog readers this post is in polish language because it refers to the situation in Poland.
In the second half of 2009 I was working in European Organization for Nuclear Research (CERN). For some time I was part of GRID development team. One of our product was/is DPM server. What is DPM? LCG Disk Pool Manager (DPM) has been developed as part of the LCG project to provide a light-weight implementation of an SRM compliant Storage Element (SE). Since gLite 3.0 it is a standard gLite component, distributed and maintained as part of the gLite release.
DPM is a disk only SE, instead of a disk + MSS implementation like dCache or Castor. It may act as a replacement for the deprecated classic SE with the following advantages :
As some of you know I am(was) active developer in ERESI project. ERESI stands for The ERESI Reverse Engineering Software Interface, its web page stands at: www.eresi-project.org.
For those who do not know the project, The ERESI Reverse Engineering Software Interface is a multi-architecture binary analysis framework with a domain-specific language tailored to reverse engineering and program manipulation.
- Feature both user-mode and kernel-mode support for instrumentation, debugging and program analysis
- Handle INTEL and SPARC machine programs (partial support for ARM, MIPS and ALPHA processors).
As some of you know, I had problems with hard disk on my server (pi3.com.pl) which immediate cause problems with availability of my blog and personal site. Bad sectors appear in one of the partition. It took some time before hosting company replace it with new hard drive. Additionally I was waiting for almost one weak until defective drive will be sent to me for creating an image of last running correct system and next restore it. In the mean time I lost access to my private mail and so on… Anyway, finally server is back so I’m adding some pictures:
I haven’t been posting for a long time. One of the main reason of this situation was of course…. TIME. As some of you is aware I changed my job which involves form me a lot of time, energy, time, travelling, time, recruitment, time, closing old task and time
Last year I was working as security consultant in great consulting company Cigital. Some of you maybe know CTO – Gary McGraw. My main task as a Security Consultant at Cigital, was working at a large financial institution as part of the Application Security Architecture team. Working on many different projects alongside the development teams within the organization to ensure security is thought about at the requirements stage of the SDLC. Then I work with the development team throughout the development, testing and deployment phase to ensure the application is secure. From this short description you can realize it is mostly high management job compared what I was doing for my last years (research). I met a lot of great people there – mostly Greek “maphia” guys (greetings especially to Alexios and John ) where we had a lot of fun not only at work Of course in company was working other great people which wasn’t Greek (greetings to David, Luca, James, Florence ).
Anyway after a year I decided to come back to what I love (research) and this is the reason why I’m now at… Microsoft.
In the mean time I was discussing in many companies but MS was more flexible, openmind and “helpful” comparing to others that I decided to go there – especially they have section (group) which perfectly matches to my job preferences.
The story of the Linux kernel 3.x…
In 2005 everybody was exited about possibility of bypass ASLR on all Linux 2.6 kernels because of the new concept called VDSO (Virtual Dynamic Shared Object). More information about this story can be found at the following link:
In short, VDSO was mmap’ed by the kernel in the user space memory always at the same fixed address. Because of that well-known technique ret-to-libc (or as some ppl prefer ROP) was possible and effective to bypass existing security mitigation in the system.
First of August 2011 was the date when I decided to publish advisory about vulnerability in OpenSSH daemon. If someone read carefully advisory he will discover this bug was found in 2008. It took me quite a long time to publish details about vulnerability. I did it from a few reasons; at first I didn’t have a time to analyse details and bug was promising (pre-authentication). In this case advisory will never be public. Problem exists in GSSAPI module (native in OpenSSH source code). I checked many packages in many systems and it seems this method of authentication (gssapi-with-mic) is enabled by default in most of them. Everything was looking very promising After some months I returned to that problem and discovered that vulnerability is _EXACTLY_ after authentication (one call) so (un)fortunately this is post-authentication bug. Next I tried to find some other way to exploit it. Again I was starting to be busy and drop this project. Because of that finally I published the advisory maybe someone else is interesting to play with that. More information can be found here and here