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: PROCESS_ALL_ACCESS PROCESS_CREATE_PROCESS PROCESS_CREATE_THREAD PROCESS_DUP_HANDLE PROCESS_QUERY_INFORMATION PROCESS_QUERY_LIMITED_INFORMATION PROCESS_SET_QUOTA PROCESS_SET_INFORMATION PROCESS_TERMINATE PROCESS_VM_OPERATION PROCESS_VM_READ PROCESS_VM_WRITE THREAD_ALL_ACCESS THREAD_DIRECT_IMPERSONATION THREAD_GET_CONTEXT THREAD_IMPERSONATE THREAD_QUERY_INFORMATION THREAD_QUERY_LIMITED_INFORMATION THREAD_SET_CONTEXT THREAD_SET_INFORMATION THREAD_SET_LIMITED_INFORMATION THREAD_SET_THREAD_TOKEN THREAD_SUSPEND_RESUME THREAD_TERMINATE 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. >> >> >> Enjoy >> >> Jakob >> -- >> Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com >> Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 >> This public discussion message is non-binding and may contain errors. >> WiseMo - Remote Service Management for PCs, Phones and Embedded >> >> ______________________________________________________________________ >> OpenSSL Project http://www.openssl.org >> User Support Mailing List openssl-users@openssl.org >> Automated List Manager majord...@openssl.org > > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
