On Thu, Apr 5, 2012 at 6:06 PM, Jakob Bohm <jb-open...@wisemo.com> wrote: > On 4/5/2012 9:01 PM, Jeffrey Walton wrote: >> >> On Thu, Apr 5, 2012 at 12:18 PM, sandeep kiran p >> <sandeepkir...@gmail.com> wrote: >>> >>> Jakob, >>> >>> The last time we had this discussions, I mentioned when 0 is passed as >>> the >>> second argument to CreateToolhelp32Snapshot, it takes a snapshot of all >>> the >>> heaps for all the processes in the system. I was wrong. This routine only >>> takes the snapshot of all heaps of a single process whose process ID is >>> passed as the second argument to the call. If a 0 is passed there, it >>> lets >>> you enumerate the current process's heap. Whereas for processes and >>> threads, >>> you get a list of all the processes and threads running in the system. >>> >>> So even with CreateToolhelp32Snapshot (with 0 passed as second argument) >>> you >>> are just looking at the current processes's heaps. The only difference >>> wrt >>> GetProcessHeap is that, with CreateToolhelp32Snapshot you would look at >>> all >>> the heaps created within the process and not just the default heap. >> >> Also, it does not make sense to allow a userland program to enumerate >> a privileged process's memory or heap. So I doubt a userland program >> will be allowed to even walk some heaps. >> >> Additionally, suppose someone actually clamps their process' DACL to >> ensure other programs [in userland under the current user] cannot read >> memory? That is, remove the privileges list in "Protected Processes >> for Windows Vista," Protected Processes in Windows Vista: > > > I obviously presumed the enumeration to be implicitly limited to those > processes whose information is not blocked by DACLs, Vista integrity > levels (hidden in the SACL for compatibility reasons), the "debug all > processes" privilege (which bypasses all process security descriptors) > etc. Don't forget SE_TCB_PRIVILEGE.
> This would be similar to walking the Linux /proc file system and looking > at all the various *map* files, skipping any files that won't open. > > The following list of permission bits are most (not all) of those that > may appear in the DACL of a process on any NT derived Windows version, > and are unrelated to any Vista specific "privileged processes" concept: Correct. They are the permissions removed in support of DRM. I use it to harden a process in general. For the heap walking, I believe - but have not tested via code - that PROCESS_VM_READ would be of interest. Interestingly, because many do not clamp their DACL, many programs are subject to various attacks. For example, we were able to shut down or corrupt nearly every Windows Antivirus Suite (http://packetstormsecurity.org/files/100564/Old-Dogs-and-New-Tricks.pdf). I also was able to read private keys from memory of GPG (or was it GPA) on Windows: pause their program by squatting an unnamed mutex after key generation and then read their memory. It was a privately reported issue, and has not been fixed. The free software folks wanted me to fund the fix despite me giving them the code to fix it in a sample program. Sigh... > The following list of permission bits are those that may appear in > the DACL of a thread on most NT derived Windows versions, and have > nothing to do with heap or memory access: Correct. Again, it was process hardening and not heap walking. If developers harden their processes (and threads), then entropy-heap-gathering falls by the wayside. Here was the link I intended to post on Protected Processes: http://msdn.microsoft.com/en-us/windows/hardware/gg463417 Jeff >>> On Thu, Apr 5, 2012 at 8:30 PM, Jakob Bohm<jb-open...@wisemo.com> >>> wrote: >>>> >>>> On 4/5/2012 2:22 PM, sandeep kiran p wrote: >>>>> >>>>> Hi, >>>>> >>>>> I had described about the deadlock we are seeing in Heap32First and >>>>> Heap32Next APIs in my previous post. Here is where you can see the >>>>> post. >>>>> >>>>> >>>>> >>>>> http://groups.google.com/group/mailing.openssl.users/browse_thread/thread/3223701a7f64a957/56d67d77c9960429?q=Deadlock+in+RAND_poll%27s+Heap32First+call# >>>>> >>>>> Believing that this is a problem with Windows APIs, we raised an >>>>> incident >>>>> with Microsoft. MS is still investigating the problem and has asked us >>>>> to >>>>> instead use GetProcessHeap and HeapWalk to enumerate the heap entries >>>>> of the >>>>> default process heap. Here is what they said >>>>> >>>>> " >>>>> >>>>> Conceptually, the biggest change between using GetProcessHeap/HeapWalk >>>>> compared to Heap32First/Heap32Next is that you are accessing a heap >>>>> handle >>>>> to which you already have access inside of the process – the default >>>>> process >>>>> heap. All components are expected to use this heap and it has >>>>> serialized >>>>> access to ensure that multiple threads from the same process do not >>>>> deadlock/corrupt the heap when accessing them simultaneously. >>>>> Heap32First, >>>>> on the other hand, accesses all heaps in the process, including private >>>>> heaps that other components in the process created. Those private heaps >>>>> might have been created with the HEAP_NO_SERIALIZE option which >>>>> disallows >>>>> application requested locking. Components (such as SSIS in your case) >>>>> typically use this option when they perform the synchronization of >>>>> memory >>>>> access on their own to gain efficiency. However, if another component >>>>> in the >>>>> process start using those private heaps, it circumvents the >>>>> synchronization >>>>> that the component puts in place. >>>>> >>>>> " >>>>> >>>>> >>>>> And since we lock the heap before reading its contents, the chances of >>>>> another thread working on the same heap at the same time are nullified. >>>>> I >>>>> have made changes to RAND_win.c to use GetProcessHeap and HeapWalk >>>>> APIs. >>>>> Would you be interested in accommodating the fix to mainstream code? >>>>> >>>>> >>>>> Please let me know your comments. >>>>> >>>>> >>>> I am afraid that MS misunderstood the situation completely and got you >>>> confused too. >>>> >>>> Most *other* uses of heap walking are about looking at your own heap to >>>> find out something about your own code, and then it makes sense to >>>> either >>>> use a heap that has internal locks (the default heap or a specific heap >>>> allocated without the HEAP_NO_SERIALIZE option), or to take the lock you >>>> yourself is using with a specific heap allocated with HEAP_NO_SERIALIZE. >>>> >>>> This is the situation which MS PSS was talking about in its answer. >>>> >>>> But the RAND code in openSSL is using the heap walking to get as many >>>> random allocation details as possible from all processes in the system >>>> to >>>> seed its RNG. >>>> >>>> So limiting the RAND code to only a single heap from its own process >>>> will >>>> effectively make that code useless and severely weaken the security of >>>> all >>>> cryptographic keys and nonces produced by openSSL. It is simply not an >>>> option. >>>> >>>> You will have to go back to MS PSS and explain that you are not trying >>>> to >>>> look at a single heap, but at all heaps of all processes and ask why the >>>> "snapshot" lock in the toolhelp32 API does not protect the "non-invasive >>>> debugger" (this is the relevant Microsoft phrase) calling toolhelp32 >>>> from >>>> locking issues in the target process. If they tell you to suspend the >>>> process being debugged, remind them that a "non-invasive debugger" is >>>> not >>>> allowed to interfere with its target in any way. >>>> ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
