Has anyone else come across IE being denied access to alternate data
streams when UAC is turned on? The same issue does not happen when IE is
Ran as Admin, even though the UAC is on. It does not happen with other apps
that are not ran with elevated privileges, just IE.
IE uses ADS’s to set the Zone.Identifier stream for downloads. Are you not
even having that stream set? What stream are you trying to access?
On Mon, Dec 1, 2014 at 11:04 AM, Dejan Maksimovic < xxxxx@gmail.com> wrote:
Has anyone else come across IE being denied access to alternate data
streams when UAC is turned on? The same issue does not happen when IE is
Ran as Admin, even though the UAC is on. It does not happen with other apps
that are not ran with elevated privileges, just IE.
Any workarounds? I am not seeing any different access to the stream, i.e.
all of the access flags/access requested are the same.
The ADS in question is our own blank stream, but it seems to occur with any
stream.
Kind regards, Dejan.
On Sun, Dec 7, 2014 at 12:57 PM, wrote:
> >Has anyone else come across IE being denied access to alternate data > streams when UAC is turned on? > > I’ve detected a similar issue, if option “Protected Mode” is enabled > inside Security-Tab of the IE settings dialog > > — > NTFSD is sponsored by OSR > > OSR is hiring!! Info at http://www.osr.com/careers > > For our schedule of debugging and file system seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer >
This sounds like it’s a security issue. In the case where it works versus doesn’t work, do you see differences in the token? My guess is that there’s a restricted token in use - so maybe there’s a privilege that must be held in order to access the ADS.
The issue happened under certain conditions, but it was reproducible to 100%: I shifted the home folder of an user to a VHD and re-mounted the VHD to the original folder. This worked good … except IE wasn’t able to create “download” files as long as IE’s “protected mode” was enabled. Starting elevated helped also.
I didn’t dig deeper, because I was just playing with VHD and my driver wasn’t installed. Just for curiosity. Does your problem disappear in case you disable IE’s “protected mode”?
It works if UAC is disabled, Protected Mode was disabled in both tests, so
I didn’t check if that made a difference.
So, UAC on, we have a problem. And we cannot start IE elevated all the time
or any time in some cases.
Tony, how would IE get that privilege then, when even without our driver,
it cannot access ADSes? (i.e. I think the problem is that it cannot access
an ADS at all, when UAC, or apparently Protected Mode, is on)
Kind regards, Dejan.
On Mon, Dec 8, 2014 at 12:31 AM, wrote:
> The issue happened under certain conditions, but it was reproducible to > 100%: I shifted the home folder of an user to a VHD and re-mounted the VHD > to the original folder. This worked good … except IE wasn’t able to > create “download” files as long as IE’s “protected mode” was enabled. > Starting elevated helped also. > > I didn’t dig deeper, because I was just playing with VHD and my driver > wasn’t installed. Just for curiosity. Does your problem disappear in case > you disable IE’s “protected mode”? > > — > NTFSD is sponsored by OSR > > OSR is hiring!! Info at http://www.osr.com/careers > > For our schedule of debugging and file system seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer >
If it is really a security issue, then my best guess is that it’s a privilege. But the best way to do this is to examine the token - set a breakpoint in the driver (maybe when you see a non-null stream portion of the name for a process called iexplorer.exe) and then dig through the token (“!token” is your friend in WinDBG) - look at the thread to see if it has an impersonation token, otherwise look at the process and examine it’s token (so “!thread” which will either show the token address or “not impersonation” which means no token for the thread and in that case “!process” which always has a token address listed).
Then compare the token where it works from the token where it does not. That will be your candidate list of things that might matter… then you may need to experiment with this by using CreateRestrictedToken (http://msdn.microsoft.com/en-us/library/windows/desktop/aa446583(v=vs.85).aspx) to figure out what it is that causes this to fail.
I’ve never had to research this specific issue, but I must admit, I find that security refusals can be some of the most frustrating issues to resolve and fix - and the techniques Microsoft seems to be sharing with developers (like sandboxing with restricted tokens) to be frustrating to track down and understand at our layer.
> > If it is really a security issue, then my best guess is that it’s a > privilege. But the best way to do this is to examine the token - set a > breakpoint in the driver (maybe when you see a non-null stream portion of > the name for a process called iexplorer.exe) and then dig through the token > (“!token” is your friend in WinDBG) - look at the thread to see if it has > an impersonation token, otherwise look at the process and examine it’s > token (so “!thread” which will either show the token address or “not > impersonation” which means no token for the thread and in that case > “!process” which always has a token address listed). > > Then compare the token where it works from the token where it does not. > That will be your candidate list of things that might matter… then you > may need to experiment with this by using CreateRestrictedToken ( > http://msdn.microsoft.com/en-us/library/windows/desktop/aa446583(v=vs.85).aspx) > to figure out what it is that causes this to fail. > > I’ve never had to research this specific issue, but I must admit, I find > that security refusals can be some of the most frustrating issues to > resolve and fix - and the techniques Microsoft seems to be sharing with > developers (like sandboxing with restricted tokens) to be frustrating to > track down and understand at our layer. > > Tony > OSR > > > — > NTFSD is sponsored by OSR > > OSR is hiring!! Info at http://www.osr.com/careers > > For our schedule of debugging and file system seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer >
On Tue, Dec 9, 2014 at 1:19 AM, Tony Mason wrote: > >>
>> >> If it is really a security issue, then my best guess is that it’s a >> privilege. But the best way to do this is to examine the token - set a >> breakpoint in the driver (maybe when you see a non-null stream portion of >> the name for a process called iexplorer.exe) and then dig through the token >> (“!token” is your friend in WinDBG) - look at the thread to see if it has >> an impersonation token, otherwise look at the process and examine it’s >> token (so “!thread” which will either show the token address or “not >> impersonation” which means no token for the thread and in that case >> “!process” which always has a token address listed). >> >> Then compare the token where it works from the token where it does not. >> That will be your candidate list of things that might matter… then you >> may need to experiment with this by using CreateRestrictedToken ( >> http://msdn.microsoft.com/en-us/library/windows/desktop/aa446583(v=vs.85).aspx) >> to figure out what it is that causes this to fail. >> >> I’ve never had to research this specific issue, but I must admit, I find >> that security refusals can be some of the most frustrating issues to >> resolve and fix - and the techniques Microsoft seems to be sharing with >> developers (like sandboxing with restricted tokens) to be frustrating to >> track down and understand at our layer. >> >> Tony >> OSR >> >> >> — >> NTFSD is sponsored by OSR >> >> OSR is hiring!! Info at http://www.osr.com/careers >> >> For our schedule of debugging and file system seminars visit: >> http://www.osr.com/seminars >> >> To unsubscribe, visit the List Server section of OSR Online at >> http://www.osronline.com/page.cfm?name=ListServer >> > >