Dangling Pointers, Now a Security Threat...
-
I hate it when my pointer dangles. Marc
Marc Clifton wrote:
I hate it when my pointer dangles.
It ain't a pointer unless it's pointing. ;)
:josh: My WPF Blog[^] The greatest danger for most of us is not that our aim is too high and we miss it, but that it is too low and we reach it. - Michelangelo (1475-1564)
-
Jonathan Afek and Adi Sharabani of Watchfire Inc. are reporting that they have discovered a reliable method for exploiting a common programming error, dangling pointers, which until now had been considered simply a quality problem. If true this could be a major problem for hundreds if not thousands of existing programs. Jonathan and Adi found the method for remotely exploiting dangling pointers while executing the company's AppScan software against a Web server. The web server crashed in the middle of the scan and upon investigation, a dangling pointer was found, not too surprising, as this is a common programming mistake, especially in C++. The pair also found they could reproduce the error by sending a specially crafted URL to the server. Next they began looking for a way to run their own code on the target machine using the dangling pointer as a starting point. Unfortunately they were successful. In August, Jonathan Afek, will present the technique he and Adi developed for exploiting the dangling pointer at the Black Hat Briefings in Las Vegas. The technique involves using generic dangling pointers to run their own shell code, and is said to work with any application in which there is a dangling pointer. Since there are hundreds perhaps thousands of applications in production with this type of error, this is a very scary discovery and application testing just got a whole lot more difficult and a whole lot more important. It is a whole new class of bugs to look for, on the same order as SQL Injection or Buffer Overflow. Thousand of existing production programs will need to be retested for vulnerability to this type of exploit. Microsoft, of Redmond, Wash., addresses the problem in IIS with one of the July security bulletins, MS07-041 . It should be pointed out that dangling pointers occur primarily in lower level languages and some languages such as Java are not vulnerable to this exploit because they have automatic mechanisms for deallocating memory. For additional information on this error take a look at SearchSecurity.com's article: New hacking technique exploits common programming error Now what do we do with all our existing applications? Test'm?
Steven S. Ashley
I also agree with Christian, that it is probably just FUD. Did anyone notice they say "that languages such as Java are not vulnerable" and "Microsoft ... addresses the problem in IIS"? The article seems to say that managed languages are not vulnerable, but isn't managed languages (or the managed engine) implemented in unmanaged languages (the core of .NET's CLR in C++)? So at the very core, they could also have some dangling pointers. BTW, what is a dangling pointer?
Luis Alonso Ramos Intelectix Chihuahua, Mexico
-
I also agree with Christian, that it is probably just FUD. Did anyone notice they say "that languages such as Java are not vulnerable" and "Microsoft ... addresses the problem in IIS"? The article seems to say that managed languages are not vulnerable, but isn't managed languages (or the managed engine) implemented in unmanaged languages (the core of .NET's CLR in C++)? So at the very core, they could also have some dangling pointers. BTW, what is a dangling pointer?
Luis Alonso Ramos Intelectix Chihuahua, Mexico
Luis Alonso Ramos wrote: BTW, what is a dangling pointer? Dangling Pointer[^]
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine. Quanehsti Pah Nation States
-
Luis Alonso Ramos wrote: BTW, what is a dangling pointer? Dangling Pointer[^]
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine. Quanehsti Pah Nation States
Ok, that will do, gracias! :) It's a pointer pointing to freed memory, and the pointer hasn't been set to NULL. Simple :)
Luis Alonso Ramos Intelectix Chihuahua, Mexico
-
Jonathan Afek and Adi Sharabani of Watchfire Inc. are reporting that they have discovered a reliable method for exploiting a common programming error, dangling pointers, which until now had been considered simply a quality problem. If true this could be a major problem for hundreds if not thousands of existing programs. Jonathan and Adi found the method for remotely exploiting dangling pointers while executing the company's AppScan software against a Web server. The web server crashed in the middle of the scan and upon investigation, a dangling pointer was found, not too surprising, as this is a common programming mistake, especially in C++. The pair also found they could reproduce the error by sending a specially crafted URL to the server. Next they began looking for a way to run their own code on the target machine using the dangling pointer as a starting point. Unfortunately they were successful. In August, Jonathan Afek, will present the technique he and Adi developed for exploiting the dangling pointer at the Black Hat Briefings in Las Vegas. The technique involves using generic dangling pointers to run their own shell code, and is said to work with any application in which there is a dangling pointer. Since there are hundreds perhaps thousands of applications in production with this type of error, this is a very scary discovery and application testing just got a whole lot more difficult and a whole lot more important. It is a whole new class of bugs to look for, on the same order as SQL Injection or Buffer Overflow. Thousand of existing production programs will need to be retested for vulnerability to this type of exploit. Microsoft, of Redmond, Wash., addresses the problem in IIS with one of the July security bulletins, MS07-041 . It should be pointed out that dangling pointers occur primarily in lower level languages and some languages such as Java are not vulnerable to this exploit because they have automatic mechanisms for deallocating memory. For additional information on this error take a look at SearchSecurity.com's article: New hacking technique exploits common programming error Now what do we do with all our existing applications? Test'm?
Steven S. Ashley
I thought there was a patch a while ago that prevented code from being executed from memory flagged as data. That would mean this "exploit" is not possible if the patch were installed and enabled. What I fail to understand is that x86 processors since the 80286 have had data and code attribute flags for segment descriptors so this kind of thing has been preventable since its introduction. That is, since the 80286 came into existence.
-
I thought there was a patch a while ago that prevented code from being executed from memory flagged as data. That would mean this "exploit" is not possible if the patch were installed and enabled. What I fail to understand is that x86 processors since the 80286 have had data and code attribute flags for segment descriptors so this kind of thing has been preventable since its introduction. That is, since the 80286 came into existence.
Rick York wrote:
What I fail to understand is that x86 processors since the 80286 have had data and code attribute flags for segment descriptors so this kind of thing has been preventable since its introduction. That is, since the 80286 came into existence.
The problem with using segmented addressing on the 386 is that the segments are applied to virtual addresses. There's only one page table, not a separate page table for each segment. Segments are only described as base address and limit, so they can only describe a contiguous block of virtual addresses. This makes loading third-party libraries pretty awkward because you'd have to cram them into the code segment - you'd have to reserve a portion of the virtual address space for 'code' and a different portion for 'data'. Retrofitting on Windows would have been pretty impossible as your program loads at low addresses (typically around 0x00400000) and kernel32.dll loads right at the top of the default process virtual address space, just before 2GB. So in practice, processes get a code segment descriptor that has a base of 0 and a limit of 4GB plus a data segment descriptor with the same properties. CS is set to that code segment descriptor and DS, SS, ES and GS to that data descriptor. FS points to a special data segment descriptor that has its base address set to the thread's Thread Information Block - each thread has its own descriptor, so that for each thread, FS : 0 is the TIB. The alternative, of using multiple segments, was horrible in the 16-bit coding days and we'd have to have kept 'near' and 'far' pointers and different memory models. Yuck. It also wouldn't have been portable: NT was originally written for a flat-model Intel i860 processor, and originally released for x86 and MIPS, which doesn't have segments either. Segment support is vestigial in x64 long mode: only FS actually does anything any more, to support Windows' use of FS to point to the TIB, as above. -- modified at 9:55 Wednesday 25th July, 2007
Stability. What an interesting concept. -- Chris Maunder
-
Rick York wrote:
What I fail to understand is that x86 processors since the 80286 have had data and code attribute flags for segment descriptors so this kind of thing has been preventable since its introduction. That is, since the 80286 came into existence.
The problem with using segmented addressing on the 386 is that the segments are applied to virtual addresses. There's only one page table, not a separate page table for each segment. Segments are only described as base address and limit, so they can only describe a contiguous block of virtual addresses. This makes loading third-party libraries pretty awkward because you'd have to cram them into the code segment - you'd have to reserve a portion of the virtual address space for 'code' and a different portion for 'data'. Retrofitting on Windows would have been pretty impossible as your program loads at low addresses (typically around 0x00400000) and kernel32.dll loads right at the top of the default process virtual address space, just before 2GB. So in practice, processes get a code segment descriptor that has a base of 0 and a limit of 4GB plus a data segment descriptor with the same properties. CS is set to that code segment descriptor and DS, SS, ES and GS to that data descriptor. FS points to a special data segment descriptor that has its base address set to the thread's Thread Information Block - each thread has its own descriptor, so that for each thread, FS : 0 is the TIB. The alternative, of using multiple segments, was horrible in the 16-bit coding days and we'd have to have kept 'near' and 'far' pointers and different memory models. Yuck. It also wouldn't have been portable: NT was originally written for a flat-model Intel i860 processor, and originally released for x86 and MIPS, which doesn't have segments either. Segment support is vestigial in x64 long mode: only FS actually does anything any more, to support Windows' use of FS to point to the TIB, as above. -- modified at 9:55 Wednesday 25th July, 2007
Stability. What an interesting concept. -- Chris Maunder
Oh god... segment registers... near and far pointers... memory models... it's a flashback... somebody help meeeeeeeee.....
Software Zen:
delete this; -
Jonathan Afek and Adi Sharabani of Watchfire Inc. are reporting that they have discovered a reliable method for exploiting a common programming error, dangling pointers, which until now had been considered simply a quality problem. If true this could be a major problem for hundreds if not thousands of existing programs. Jonathan and Adi found the method for remotely exploiting dangling pointers while executing the company's AppScan software against a Web server. The web server crashed in the middle of the scan and upon investigation, a dangling pointer was found, not too surprising, as this is a common programming mistake, especially in C++. The pair also found they could reproduce the error by sending a specially crafted URL to the server. Next they began looking for a way to run their own code on the target machine using the dangling pointer as a starting point. Unfortunately they were successful. In August, Jonathan Afek, will present the technique he and Adi developed for exploiting the dangling pointer at the Black Hat Briefings in Las Vegas. The technique involves using generic dangling pointers to run their own shell code, and is said to work with any application in which there is a dangling pointer. Since there are hundreds perhaps thousands of applications in production with this type of error, this is a very scary discovery and application testing just got a whole lot more difficult and a whole lot more important. It is a whole new class of bugs to look for, on the same order as SQL Injection or Buffer Overflow. Thousand of existing production programs will need to be retested for vulnerability to this type of exploit. Microsoft, of Redmond, Wash., addresses the problem in IIS with one of the July security bulletins, MS07-041 . It should be pointed out that dangling pointers occur primarily in lower level languages and some languages such as Java are not vulnerable to this exploit because they have automatic mechanisms for deallocating memory. For additional information on this error take a look at SearchSecurity.com's article: New hacking technique exploits common programming error Now what do we do with all our existing applications? Test'm?
Steven S. Ashley
Dangling pointers are no more likely in C++ than in C, Pascal, or assembly language. Further, dangling pointers in C++ are easily avoided by following this rule: Don't use operator new unless: 1. you are passing its return value to an auto_ptr 2. you are writing a constructor and you know that there is a delete of member holding the pointer in the destructor I know this works because I use valgrind, purify, and bounds checker. Even if you are not worried about forgetting to delete things yourself, C++ pretty much requires that you obey these rules because of exceptions. Some darn fool function that you call that was written by someone else is likely to throw an exception and so you get stuck planning for exception even if you don't write them yourself. As for the crowd who want to brag that Java/C#/Ruby don't have dangling pointers, I say this: I'll tried my C++ program performance for yours anytime -- especially in a large, long lived program. If you just learn to use the language, its not that hard to avoid all the problems these interpreters are supposed solve -- particularly since the STL came into C++. Most of the C++ language portability issues disappeared around 2002. At that time, porting a large Java application to Sun, Windows, HPUX, and AIX was still a challenge due to minor differences in the VMs. I don't know about nowadays though. Sorry -- as you can see I'm a C++ enthusiast. Lowell C++ Evangelist http://cplusplus.bordoon.com/index.html
-
Steven Ashley wrote:
Now what do we do with all our existing applications?
Depends, where they written properly to start with ? What's a 'dangling pointer', one that's been deleted and not set to NULL ? One that's not been deleted, and is out of scope ? What sort of URL could they send to a server, that would find an abandoned pointer, and what could they do with it ? One assumes this is a problem only if the program in question is, for example, a COM dll being used by an ASP website ? The article in short says 'this is a very scary problem' ( every one who says this runs a 'security firm' and has vested interest in creating fear ) and 'once you know the value of the pointer, it's game over'. So, again, how does a URL work out a pointer value ? Sounds like FUD to me.
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
got my vote, sounds a bit far fetched me as well. even if you found an entry point which is a 'dangleing pointer' the chance it being referenced or used before its reinitialised is a tad silm as that would course a error/crash anyhow. better off looking at process injection and run time memory editting to change a programs path etc. dangling pointers... cant see this being much of a threat due to the overwhelming knownledge required about the software and said pointer to abuse it. like memory overruns you need to know where it's going to overrun to and the size required. i'd be more worried at those myself :) hmm you may be able to do a similar thing with pointers but still requires local access and some smart injection of code into the process via the pointer which would then be changed, null'd or just never used again. hey i could be wrong :) will be interesting read if i am.
-
Jonathan Afek and Adi Sharabani of Watchfire Inc. are reporting that they have discovered a reliable method for exploiting a common programming error, dangling pointers, which until now had been considered simply a quality problem. If true this could be a major problem for hundreds if not thousands of existing programs. Jonathan and Adi found the method for remotely exploiting dangling pointers while executing the company's AppScan software against a Web server. The web server crashed in the middle of the scan and upon investigation, a dangling pointer was found, not too surprising, as this is a common programming mistake, especially in C++. The pair also found they could reproduce the error by sending a specially crafted URL to the server. Next they began looking for a way to run their own code on the target machine using the dangling pointer as a starting point. Unfortunately they were successful. In August, Jonathan Afek, will present the technique he and Adi developed for exploiting the dangling pointer at the Black Hat Briefings in Las Vegas. The technique involves using generic dangling pointers to run their own shell code, and is said to work with any application in which there is a dangling pointer. Since there are hundreds perhaps thousands of applications in production with this type of error, this is a very scary discovery and application testing just got a whole lot more difficult and a whole lot more important. It is a whole new class of bugs to look for, on the same order as SQL Injection or Buffer Overflow. Thousand of existing production programs will need to be retested for vulnerability to this type of exploit. Microsoft, of Redmond, Wash., addresses the problem in IIS with one of the July security bulletins, MS07-041 . It should be pointed out that dangling pointers occur primarily in lower level languages and some languages such as Java are not vulnerable to this exploit because they have automatic mechanisms for deallocating memory. For additional information on this error take a look at SearchSecurity.com's article: New hacking technique exploits common programming error Now what do we do with all our existing applications? Test'm?
Steven S. Ashley
Well gee... A "pointer" is to memory for data right? ...not a "CALLBACK" or Event Pointer where one could possibly expect to get the indirect address loaded into the execution register (IP). What exactly could you do with a dangling data area pointer? I agree with an earlier poster; If you can use a "Pointer" for something malicious then why not go ahead and overlay some executable code somewhere and be SURE you get control of the CPU... that's what the Virus writers do...
-
Rick York wrote:
What I fail to understand is that x86 processors since the 80286 have had data and code attribute flags for segment descriptors so this kind of thing has been preventable since its introduction. That is, since the 80286 came into existence.
The problem with using segmented addressing on the 386 is that the segments are applied to virtual addresses. There's only one page table, not a separate page table for each segment. Segments are only described as base address and limit, so they can only describe a contiguous block of virtual addresses. This makes loading third-party libraries pretty awkward because you'd have to cram them into the code segment - you'd have to reserve a portion of the virtual address space for 'code' and a different portion for 'data'. Retrofitting on Windows would have been pretty impossible as your program loads at low addresses (typically around 0x00400000) and kernel32.dll loads right at the top of the default process virtual address space, just before 2GB. So in practice, processes get a code segment descriptor that has a base of 0 and a limit of 4GB plus a data segment descriptor with the same properties. CS is set to that code segment descriptor and DS, SS, ES and GS to that data descriptor. FS points to a special data segment descriptor that has its base address set to the thread's Thread Information Block - each thread has its own descriptor, so that for each thread, FS : 0 is the TIB. The alternative, of using multiple segments, was horrible in the 16-bit coding days and we'd have to have kept 'near' and 'far' pointers and different memory models. Yuck. It also wouldn't have been portable: NT was originally written for a flat-model Intel i860 processor, and originally released for x86 and MIPS, which doesn't have segments either. Segment support is vestigial in x64 long mode: only FS actually does anything any more, to support Windows' use of FS to point to the TIB, as above. -- modified at 9:55 Wednesday 25th July, 2007
Stability. What an interesting concept. -- Chris Maunder
I see. Thanks for the info Mike. I have not read much on the loading process or details of the memory model so that was interesting. I believe NT was also ported to the PowerPC and Alpha chips, neither of which have segments either, as well as several embedded processors. Personally, I wouldn't mind a setup where the memory model was the "far" style with multiple segments as long is it was all "transparent" (a pointer is a pointer) but I suspect that could have severe performance implications. I certainly would not wish for a return to the mixing of far and near pointers though. That was heinous. It still annoys to see all of the Ls that prefix so many of the win32 data types.
-
I also agree with Christian, that it is probably just FUD. Did anyone notice they say "that languages such as Java are not vulnerable" and "Microsoft ... addresses the problem in IIS"? The article seems to say that managed languages are not vulnerable, but isn't managed languages (or the managed engine) implemented in unmanaged languages (the core of .NET's CLR in C++)? So at the very core, they could also have some dangling pointers. BTW, what is a dangling pointer?
Luis Alonso Ramos Intelectix Chihuahua, Mexico
Luis Alonso Ramos wrote:
The article seems to say that managed languages are not vulnerable, but isn't managed languages (or the managed engine) implemented in unmanaged languages
They're talking from the point of view of what's open to the application developer. In terms of the language features this particular vulnerability is not possible. But we've always been aware of this. Re: the CLR, if it's implemented in modern C++, which it should be given its newness, then I would expect pointer errors to be much reduced.
Kevin