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.
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:
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
The following list of permssion 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:
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.
--
Jakob Bohm, CIO, partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. direct: +45 31 13 16 10
<call:+4531131610>
This message is only for its intended recipient, delete if misaddressed.
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
