UAC, IE and alternate data streams access denied

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.

Windows 7, we did not test on other OSes yet.

Kind regards, Dejan.

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.

Windows 7, we did not test on other OSes yet.

Kind regards, Dejan.
— 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

>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

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.

Tony
OSR

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.

Tony
OSR

I finally had time to test this issue.

The tokens are identical in both scenarios:

TS Session ID: 0x1
User: S-1-5-21-3163543439-3517584321-1494237172-1000
User Groups:
00 S-1-5-21-3163543439-3517584321-1494237172-513
Attributes - Mandatory Default Enabled
01 S-1-1-0
Attributes - Mandatory Default Enabled
02 S-1-5-114
Attributes - DenyOnly
03 S-1-5-21-3163543439-3517584321-1494237172-1001
Attributes - Mandatory Default Enabled
04 S-1-5-32-544
Attributes - DenyOnly
05 S-1-5-32-545
Attributes - Mandatory Default Enabled
06 S-1-5-4
Attributes - Mandatory Default Enabled
07 S-1-2-1
Attributes - Mandatory Default Enabled
08 S-1-5-11
Attributes - Mandatory Default Enabled
09 S-1-5-15
Attributes - Mandatory Default Enabled
10 S-1-5-113
Attributes - Mandatory Default Enabled
11 S-1-5-5-0-79864
Attributes - Mandatory Default Enabled LogonId
12 S-1-2-0
Attributes - Mandatory Default Enabled
13 S-1-5-64-10
Attributes - Mandatory Default Enabled
14 S-1-16-8192
Attributes - GroupIntegrity GroupIntegrityEnabled
Primary Group: S-1-5-21-3163543439-3517584321-1494237172-513
Privs:
19 0x000000013 SeShutdownPrivilege Attributes -
23 0x000000017 SeChangeNotifyPrivilege Attributes - Enabled
Default
25 0x000000019 SeUndockPrivilege Attributes -
33 0x000000021 SeIncreaseWorkingSetPrivilege Attributes -
34 0x000000022 SeTimeZonePrivilege Attributes -
Authentication ID: (0,1389a)
Impersonation Level: Anonymous
TokenType: Primary
Source: User32 TokenFlags: 0x2e00 ( Token in use )
Token ID: 84c37 ParentToken ID: 1389d
Modified ID: (0, 84c5c)
RestrictedSidCount: 0 RestrictedSids: 00000000
OriginatingLogonSession: 3e7

Kind regards, Dejan.

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
>

Correction, for some reason, even after reboot the UAC didn’t turn off. So
after a second reboot, and UAC off, a lot more privileges:
Thread is not impersonating. Using process token…
_EPROCESS 87949a68, _TOKEN 00000000
TS Session ID: 0x1
User: S-1-5-21-3163543439-3517584321-1494237172-1000
User Groups:
00 S-1-5-21-3163543439-3517584321-1494237172-513
Attributes - Mandatory Default Enabled
01 S-1-1-0
Attributes - Mandatory Default Enabled
02 S-1-5-114
Attributes - Mandatory Default Enabled
03 S-1-5-21-3163543439-3517584321-1494237172-1001
Attributes - Mandatory Default Enabled
04 S-1-5-32-544
Attributes - Mandatory Default Enabled Owner
05 S-1-5-32-545
Attributes - Mandatory Default Enabled
06 S-1-5-4
Attributes - Mandatory Default Enabled
07 S-1-2-1
Attributes - Mandatory Default Enabled
08 S-1-5-11
Attributes - Mandatory Default Enabled
09 S-1-5-15
Attributes - Mandatory Default Enabled
10 S-1-5-113
Attributes - Mandatory Default Enabled
11 S-1-5-5-0-79973
Attributes - Mandatory Default Enabled LogonId
12 S-1-2-0
Attributes - Mandatory Default Enabled
13 S-1-5-64-10
Attributes - Mandatory Default Enabled
14 S-1-16-12288
Attributes - GroupIntegrity GroupIntegrityEnabled
Primary Group: S-1-5-21-3163543439-3517584321-1494237172-513
Privs:
05 0x000000005 SeIncreaseQuotaPrivilege Attributes -
08 0x000000008 SeSecurityPrivilege Attributes -
09 0x000000009 SeTakeOwnershipPrivilege Attributes -
10 0x00000000a SeLoadDriverPrivilege Attributes -
11 0x00000000b SeSystemProfilePrivilege Attributes -
12 0x00000000c SeSystemtimePrivilege Attributes -
13 0x00000000d SeProfileSingleProcessPrivilege Attributes -
14 0x00000000e SeIncreaseBasePriorityPrivilege Attributes -
15 0x00000000f SeCreatePagefilePrivilege Attributes -
17 0x000000011 SeBackupPrivilege Attributes -
18 0x000000012 SeRestorePrivilege Attributes -
19 0x000000013 SeShutdownPrivilege Attributes -
20 0x000000014 SeDebugPrivilege Attributes -
22 0x000000016 SeSystemEnvironmentPrivilege Attributes -
23 0x000000017 SeChangeNotifyPrivilege Attributes - Enabled
Default
24 0x000000018 SeRemoteShutdownPrivilege Attributes -
25 0x000000019 SeUndockPrivilege Attributes -
28 0x00000001c SeManageVolumePrivilege Attributes -
29 0x00000001d SeImpersonatePrivilege Attributes - Enabled
Default
30 0x00000001e SeCreateGlobalPrivilege Attributes - Enabled
Default
33 0x000000021 SeIncreaseWorkingSetPrivilege Attributes -
34 0x000000022 SeTimeZonePrivilege Attributes -
35 0x000000023 SeCreateSymbolicLinkPrivilege Attributes -
Authentication ID: (0,138b7)
Impersonation Level: Anonymous
TokenType: Primary
Source: User32 TokenFlags: 0x2000 ( Token in use )
Token ID: 73920 ParentToken ID: 0
Modified ID: (0, 73944)
RestrictedSidCount: 0 RestrictedSids: 00000000
OriginatingLogonSession: 3e7

Now, other than injecting a DLL into IE, and changing all CreateFile calls,
what else can be done here?

Kind regards, Dejan.

On Sun, Dec 28, 2014 at 9:54 PM, Dejan Maksimovic <
xxxxx@gmail.com> wrote:

I finally had time to test this issue.

The tokens are identical in both scenarios:

TS Session ID: 0x1
User: S-1-5-21-3163543439-3517584321-1494237172-1000
User Groups:
00 S-1-5-21-3163543439-3517584321-1494237172-513
Attributes - Mandatory Default Enabled
01 S-1-1-0
Attributes - Mandatory Default Enabled
02 S-1-5-114
Attributes - DenyOnly
03 S-1-5-21-3163543439-3517584321-1494237172-1001
Attributes - Mandatory Default Enabled
04 S-1-5-32-544
Attributes - DenyOnly
05 S-1-5-32-545
Attributes - Mandatory Default Enabled
06 S-1-5-4
Attributes - Mandatory Default Enabled
07 S-1-2-1
Attributes - Mandatory Default Enabled
08 S-1-5-11
Attributes - Mandatory Default Enabled
09 S-1-5-15
Attributes - Mandatory Default Enabled
10 S-1-5-113
Attributes - Mandatory Default Enabled
11 S-1-5-5-0-79864
Attributes - Mandatory Default Enabled LogonId
12 S-1-2-0
Attributes - Mandatory Default Enabled
13 S-1-5-64-10
Attributes - Mandatory Default Enabled
14 S-1-16-8192
Attributes - GroupIntegrity GroupIntegrityEnabled
Primary Group: S-1-5-21-3163543439-3517584321-1494237172-513
Privs:
19 0x000000013 SeShutdownPrivilege Attributes -
23 0x000000017 SeChangeNotifyPrivilege Attributes - Enabled
Default
25 0x000000019 SeUndockPrivilege Attributes -
33 0x000000021 SeIncreaseWorkingSetPrivilege Attributes -
34 0x000000022 SeTimeZonePrivilege Attributes -
Authentication ID: (0,1389a)
Impersonation Level: Anonymous
TokenType: Primary
Source: User32 TokenFlags: 0x2e00 ( Token in use )
Token ID: 84c37 ParentToken ID: 1389d
Modified ID: (0, 84c5c)
RestrictedSidCount: 0 RestrictedSids: 00000000
OriginatingLogonSession: 3e7

Kind regards, Dejan.

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
>>
>
>