On Mon, Oct 14, 2013 at 4:34 AM, Ivan Zhakov <i...@visualsvn.com> wrote:
> On 12 October 2013 18:48, Jeff Trawick <traw...@gmail.com> wrote: > > With APR on Windows, creating shared memory or a cross-process mutex > with a > > "file" name parameter results in a resource being created with a "Global" > > prefix, which in turn restricts the call to Administrator (or more > > accurately, a thread with the specific privilege > > to make that call; let's just call that "Administrator" for simplicity). > (I > > think this is just for shared memory???) > > > > A typical way to encounter this is that some dude in httpd-land decides > that > > mod_lua should start creating APR shared memory at startup and a filename > > should always be specified, and suddenly httpd running as you on Windows > can > > no longer use mod_lua. Any number of other httpd modules try do > something > > similar (though I haven't investigated if there's a way to configure > around > > it); additionally, APR's testshm won't work as a regular user. > > > > The attached patch uses "Local" as the prefix if the calling thread > doesn't > > have the necessary privilege to create one under the global namespace. > But > > this function is also used for attach-type operations, > > > > Has anyone investigated this before? > > > Jeff, > > It looks like very dangerous change. Local and Global namespaces are > completely separate, thus priviliged process could not access > shm/mutex created by unprivileged process. Objects in local kernel > namespace are per session, while objects in global kernel namespace > are shared across all sessions, that's why process need additional > privilege to create them. > First, make sure you're looking at what was committed ( http://svn.apache.org/viewvc?view=revision&revision=r1531768), which is slightly different and may have some different considerations. For analysis as a security concern, I think it comes down to this: * no elevation of privileges * no change to ACL/permissions of shared memory segments The code ends up acting the same as if the apr app had access to the global parameter to res_name_from_filename() and could make the adjustments itself. Some of your comments lead me to believe you thought there was a privilege escalation. (The name of the API keyword "PRIVILEGE_SET_ALL_NECESSARY" is disturbing, but it means everything-in-privilege-set-is-necessary, not set-all-privileges-I-need.) How is the privilege escalation occurring? Or, do you agree there is no privilege escalation? > > Services are started in separate "session 0", while interactive > processes uses dedicated session for every user/rdp connection. > understood > > Your patch may also break atomic "create or open" code: > [[ > rv == apr_shm_create(); > if (rv == ALREADY_EXIST) > rv = apr_shm_attach() > ]] > The patch doesn't break this AFAICT, but it doesn't make this work in all circumstances either. Assume old code (e.g., 1.5.x branch), and a privileged process successfully creates a shm segment with a particular name under Global. If an unprivileged client tries the code sequence above, it gets access-denied from apr_shm_create(), not already-exist. (Is that the testcase you're referring to?) If the second process to run is also privileged, it gets the already-exists feedback and can then attach. > > Suppose Windows services created shm object in global namespace, > interactive process wanted to access it using code above. > apr_shm_create() detects that process is not privileged and creates > shm object in local namespace, which is wrong IMHO. > It doesn't work now either. (See above.) Is there a way to make it work within the constraints of the current API? I guess apr_shm_create() for unprivileged processes would need to check via some other API to see if it already exists, in order to allow that idiom to work for unprivileged processes that need to attach to a shm segment created by privileged processes. > > Change process privileges as side effect of apr_shm_attach() is also > nasty behavior imho. > I assert that this is not happening ;) --/-- Thanks for looking at this in detail/please let me know where we agree/disagree at this point. > > -- > Ivan Zhakov > -- Born in Roswell... married an alien... http://emptyhammock.com/
