How to protect HKEY_LOCAL_MACHINE keys from user mode access under

Hello,

I work with CE6 and would like to protect all HKEY_LOCAL_MACHINE
registry keys so that (malicious) applications running in the user
mode cannot modify them (for example device driver registry keys!).
CE6 distinguishes between user and kernel mode, so it must be possible
to do that, doesn't it?

Thank you,
Peter

Dean
Mon Mar 24 06:53:10 PDT 2008

No. The ability to write to the registry has nothing to do with user vs
kernel mode.

In CE6, an application is either fully trusted and can make any call that is
legal for a user mode process or not allowed to run at all. This is a
change from CE5 where there were multiple levels of trust. In that model
there were certain registry keys that could not be accessed by untrusted
applications. However the keys that were protected were predefined; I don't
believe there was a mechanism that allowed you to add more keys to the list.

--
Dean Ramsier - eMVP
BSQUARE Corporation


<peach.voser@gmx.ch> wrote in message
news:48024898-bab1-47de-8c90-3cfb597a5fc0@s50g2000hsb.googlegroups.com...
> Hello,
>
> I work with CE6 and would like to protect all HKEY_LOCAL_MACHINE
> registry keys so that (malicious) applications running in the user
> mode cannot modify them (for example device driver registry keys!).
> CE6 distinguishes between user and kernel mode, so it must be possible
> to do that, doesn't it?
>
> Thank you,
> Peter

peach
Tue Mar 25 04:26:32 PDT 2008

Does this mean that a malicious application can manipulate registry
keys of an essential device driver (such as the LCD device driver) and
the device is "dead" at the next reboot? The device must be send to
the support center to repair it in this case... :-(

Thank you,
Peter

Valter
Tue Mar 25 04:42:30 PDT 2008

peach.voser@gmx.ch wrote in
news:1ed9d920-790d-4036-977f-993dff76cb7c@n77g2000hse.googlegroups.co
m:

> Does this mean that a malicious application can manipulate
> registry keys of an essential device driver (such as the LCD
> device driver) and the device is "dead" at the next reboot? The
> device must be send to the support center to repair it in this
> case... :-(

That's true if the driver initialization was not inside the boot
registry of a device that support hive-based registry.
To avoid this sort of "device bricking" issues you may provide a
mechanism to reset the registry from the bootloader or restore it to a
previously working state.
Even with this kind of protection in place (that will force a user to
re-configure some of the device settings, at least) a malicious
application tool can write the keys to load a kernel-mode driver and
erase flash or do some operations of this kind.

--
Valter Minute
www.fortechembeddedlabs.it
Training, support and development for Windows CE
(the reply address of this message is invalid)

Jack
Wed Mar 26 03:04:32 PDT 2008

so how can you prevent then a unknown application to run its driver in
the kernel mode?

Valter
Wed Mar 26 03:15:41 PDT 2008

Jack <unseen_coder@hotmail.com> wrote in
news:73df1cbd-e129-454e-ac21-f2db98446f6b@i7g2000prf.googlegroups.com
:

> so how can you prevent then a unknown application to run its
> driver in the kernel mode?

You can prevent unknown applications from running but if you let them
run they can do everything a trusted application can do.
If you provide a signature mechanism users will be able to install
only applications that are signed and trusted.
Obviously it's up to you to check that those application won't do some
illegal or dangerous operations before you allow them to be signed.
IIRC during the presentation of CE 6.0 the new security mechanism was
presented as the first step trough a more granular approach, similar
to the one you have on desktop operating systems.
A simple "trick" would be a modified version of coredll that exports
the same APIs but "filters" some API calls allowing only trusted
modules to access them (as it happened in CE 5).
You can customize coredll during it's link phase, inserting some
libraries that re-define the APIs you need to "filter" before the
"official" libs are linked. Then you can take the "official" libs and
use them to build an alternate DLL that will be called by coredll
after the caller has been verified and allowed to access that specific
API (or registry key).
This mechanism will obviously add some overhead to function calls but,
in the specific case of registry access, that should not be such a big
issue.
I don't know if redistributing a "customized" version of those API may
break CE license.

--
Valter Minute
www.fortechembeddedlabs.it
Training, support and development for Windows CE
(the reply address of this message is invalid)

Sue
Wed Mar 26 07:15:23 PDT 2008

Peter asked me to comment on this thread, so I'll give my view of this.

Valter is right, in CE6 you have only two choices - completely block an
EXE/DLL from running, or give it so much privilege it can do anything.
There are some restrictions that keep user-mode code from doing certain
things, but if an EXE is allowed to run, nothing keeps it from loading its
own DLL (if that is allowed to run too) into kernel mode where it can do
anything. So, really, your only chance to block a malicious application is
to keep it from running at all.

I don't think Valter's mechanism of modifying coredll is sufficient. It
would make it less convenient for a malicious application to call an OS API,
but anything coredll can do, user code can do. Coredll mainly just jumps to
OS thunks; a user application could jump to those directly without going
through coredll if someone worked on it enough. Any fix would have to be on
the OS side of the world, not inside the application side of the world.

It's really unfortunate to have lost important security functionality like
this on CE6, so let me explain a little bit why it happened. First, suppose
we were to convert our previous security model (not run / run untrusted /
run trusted) to CE6. There'd be some complicated cases for combining those
old semantics with the new user vs. kernel mode restrictions. (For example,
we'd have to go through every operation that previously required trust, and
decide whether it should now be callable only in kernel mode, or in kernel +
trusted users, or...?) It would be a pretty serious cost in testing for
security holes and backwards-compatibility breaks. Also, the old security
model was/is beginning to wear thin -- it's not granular enough in privilege
levels. So why invest in porting our old security model if we're looking
forward to something new? But an entirely new security model would have
been too much work to fit into CE6. Add on top of that the fact that a huge
portion of our embedded customers either don't care to lock down their
devices at all, or prefer to completely lock them down so only their own
code can run. Most embedded devices don't allow 3rd party code to run or
even have a mechanism to get it on there.

So in the end the decision was made (not by me, of course, I'm too low on
the pay scale :-) ) to only support a 1-tier security model in CE6. We know
this is a problem, though, and you can expect that we are working on
something better for the future.

Sue
sloh@microsoft.com (remove "online" from reply-to address)
http://blogs.msdn.com/ce_base/
_____________________________________________________________
This posting is provided "AS IS" with no warranties, and confers no rights.
_____________________________________________________________

Valter
Wed Mar 26 07:41:50 PDT 2008

"Sue Loh [MS]" <sloh@online.microsoft.com> wrote in
news:310013F8-C4AC-4A10-86DE-EAFEDB5FA687@microsoft.com:

> Peter asked me to comment on this thread, so I'll give my view of
> this.
>
> Valter is right, in CE6 you have only two choices - completely
> block an EXE/DLL from running, or give it so much privilege it can
> do anything. There are some restrictions that keep user-mode code
> from doing certain things, but if an EXE is allowed to run,
> nothing keeps it from loading its own DLL (if that is allowed to
> run too) into kernel mode where it can do anything. So, really,
> your only chance to block a malicious application is to keep it
> from running at all.
>
> I don't think Valter's mechanism of modifying coredll is
> sufficient. It would make it less convenient for a malicious
> application to call an OS API, but anything coredll can do, user
> code can do. Coredll mainly just jumps to OS thunks; a user
> application could jump to those directly without going through
> coredll if someone worked on it enough. Any fix would have to be
> on the OS side of the world, not inside the application side of
> the world.

I agree about the fact that you can't fix this sort of issues inside
the caller process.
My solution (more a "hack" than a real solution) was meant to add an
additional protection on a specific device against "generic" treats
like viruses that may have been able to bypess the run/don't run
security layer.
You may be able to "filter" calls on the OS side by changing the API
tables, I suppose, but this could bring in more problems and
compatibility issues than the ones it can fix.

A more granular mechanism would be welcomed if it does not impact
too much on performances, IMHO.
Some sort of "pluggable" layer with different alternatives with
reduced features and little performance impact or full-features and
higher impact would be great.
Most of my customers have "closed" devices or, at least, devices
meant to run only a very small set of applications, so they don't
care much about "virus-like" issues and, at most, they may want to
prevent application bugs from damaging the OS configuration, but I
understand that security is a big issue for people making Windows
Mobile devices or other "open" devices.

> It's really unfortunate to have lost important security
> functionality like this on CE6, so let me explain a little bit why
> it happened.
[...]
> So in the end the decision was made (not by me, of course, I'm too
> low on the pay scale :-) ) to only support a 1-tier security model
> in CE6. We know this is a problem, though, and you can expect
> that we are working on something better for the future.

This kind of information is very useful, at least to reply to
customers questions about that specific issue.
Thank you very much for having explained this on the newsgroup.

One of the thing I like about CE is that the development process is
more "transparent" than the one on the "desktop side". Or maybe one
of the things I don't like about other microsoft OSes is that their
development process isn' so transparent...

--
Valter Minute
www.fortechembeddedlabs.it
Training, support and development for Windows CE
(the reply address of this message is invalid)

Sue
Fri Mar 28 06:00:14 PDT 2008

> One of the thing I like about CE is that the development process is
> more "transparent" than the one on the "desktop side".

Thanks Valter, that's one of the things I like about CE too. :-)

Sue
sloh@microsoft.com (remove "online" from reply-to address)
http://blogs.msdn.com/ce_base/
_____________________________________________________________
This posting is provided "AS IS" with no warranties, and confers no rights.
_____________________________________________________________

Jack
Fri Apr 04 01:28:03 PDT 2008

yeah, like walter i'm very glad that there exist this kind of
community...

out of the comment of sue:
but if an EXE is allowed to run, nothing keeps it from loading its
own DLL (if that is allowed to run too) into kernel mode where it can
do
anything.

in my understanding the way the dll is loaded is defined by a flag in
the *.bib file.
in the registry only exist the possiblility to load an dll as in user
mode instead in the kernel mode but not vice versa.

the permission for an executable depends on the trusted / not trusted
module and if the romflag 0x000002 (disable full kernel mode) is not
set, everything
which is not built in the kernel is not allowed to run in kernel mode
at all.

so how can a executable load its own dll in the kernel mode in ce 6.0?
(since the SetKMode is not allowed anymore like in windows ce 5)

Michael
Fri Apr 04 02:58:50 PDT 2008

On 4 avr, 10:28, Jack <unseen_co...@hotmail.com> wrote:
> yeah, like walter i'm very glad that there exist this kind of
> community...
>
> out of the comment of sue:
> but if an EXE is allowed to run, nothing keeps it from loading its
> own DLL (if that is allowed to run too) into kernel mode where it can
> do
> anything.
>
> in my understanding the way the dll is loaded is defined by a flag in
> the *.bib file.
> in the registry only exist the possiblility to load an dll as in user
> mode instead in the kernel mode but not vice versa.
>
> the permission for an executable depends on the trusted / not trusted
> module and if the romflag 0x000002 (disable full kernel mode) is not
> set, everything
> which is not built in the kernel is not allowed to run in kernel mode
> at all.
>
> so how can a executable load its own dll in the kernel mode in ce 6.0?
> (since the SetKMode is not allowed anymore like in windows ce 5)

Hi Jack,

The user application can for instance add some regsitry keys (why not,
under HKLM\Drivers\BuiltIn), and call ActivateDevice on them (writing
on these keys is allowed in CE 6 if the application can run). Then the
driver will be loaded into the kernel space (if the user mode flag was
not set). That's it ! If you use a hive based registry, the driver
will be launched by the kernel at the next boot.

Hope this helps,

Mike

Jack
Fri Apr 04 03:45:53 PDT 2008

mike, thanks for the answer.

To make shure that i understand you correctly i try to repeat your
post on my words:
this mean that every driver which register itself under the HKLM
\Drivers\BuiltIn will be loaded as KernelMode driver?

Well i thought that the kernel mode drivers (only the ones which are
marked so in the *.bib file) are loaded by the kernel devicemanager
dll which is loaded by the nk.exe in kernel mode.
all other drivers are loaded by a udevice.exe in user mode.

did i got that concept wrong?

Michael
Fri Apr 04 04:26:23 PDT 2008

On 4 avr, 12:45, Jack <unseen_co...@hotmail.com> wrote:
> mike, thanks for the answer.
>
> To make shure that i understand you correctly i try to repeat your
> post on my words:
> this mean that every driver which register itself under the HKLM
> \Drivers\BuiltIn will be loaded as KernelMode driver?
>
> Well i thought that the kernel mode drivers (only the ones which are
> marked so in the *.bib file) are loaded by the kernel devicemanager
> dll which is loaded by the nk.exe in kernel mode.
> all other drivers are loaded by a udevice.exe in user mode.
>
> did i got that concept wrong?

"every driver which register itself under the HKLM
> \Drivers\BuiltIn will be loaded as KernelMode driver"
yes if the User mode flag is not set.
If the driver DLL appears in the .bib file with the flag SH (in fact,
no "K" flag), and the user mode flag is not set, a warning will appear
at startup (the dll is mapped into the user space, but this is a
kernel mode driver). In the same way, if the dll is noted as SHK in
the .bib (meaning mapped into the kernel space), and you set the flag
User rmode, a warning will appear.
You can put your DLL into the "FILES" section if you want it to be
mapped automatically into the good space.

Mike

Valter
Fri Apr 04 10:12:22 PDT 2008

Jack <unseen_coder@hotmail.com> wrote in news:962fbaa9-bce3-41d9-a36e-
4c1739c2d702@s50g2000hsb.googlegroups.com:

> mike, thanks for the answer.
>
> To make shure that i understand you correctly i try to repeat your
> post on my words:
> this mean that every driver which register itself under the HKLM
> \Drivers\BuiltIn will be loaded as KernelMode driver?
>
> Well i thought that the kernel mode drivers (only the ones which are
> marked so in the *.bib file) are loaded by the kernel devicemanager
> dll which is loaded by the nk.exe in kernel mode.
> all other drivers are loaded by a udevice.exe in user mode.
>
> did i got that concept wrong?
>

The K flag is needed for modules that are part of the image and must
be fixed-up by makeimage to run in user or kernel mode (or both using
the "K." filename prefix trick).
If you load a DLL from a mass storage device it will be fixed-up at
runtime so it may run in user or in kernel mode.

It should even not export the driver entry points (so not being a
driver at all) if it can do all it's "dirty work" inside its DllMain.


--
Valter Minute
www.fortechembeddedlabs.it
Training, support and development for Windows CE
(the reply address of this message is invalid)

Jack
Mon Apr 07 00:51:31 PDT 2008

On 4 Apr., 19:12, Valter Minute
<v_a_l_t_e_r.m_i_n_u_t_e@g_m_a_i_l.com> wrote:
> Jack <unseen_co...@hotmail.com> wrote in news:962fbaa9-bce3-41d9-a36e-
> 4c1739c2d...@s50g2000hsb.googlegroups.com:
>
> > mike, thanks for the answer.
>
> > To make shure that i understand you correctly i try to repeat your
> > post on my words:
> > this mean that every driver which register itself under the HKLM
> > \Drivers\BuiltIn will be loaded as KernelMode driver?
>
> > Well i thought that the kernel mode drivers (only the ones which are
> > marked so in the *.bib file) are loaded by the kernel devicemanager
> > dll which is loaded by the nk.exe in kernel mode.
> > all other drivers are loaded by a udevice.exe in user mode.
>
> > did i got that concept wrong?
>
> The K flag is needed for modules that are part of the image and must
> be fixed-up by makeimage to run in user or kernel mode (or both using
> the "K." filename prefix trick).
> If you load a DLL from a mass storage device it will be fixed-up at
> runtime so it may run in user or in kernel mode.
>
> It should even not export the driver entry points (so not being a
> driver at all) if it can do all it's "dirty work" inside its DllMain.
>
> --
> Valter Minutewww.fortechembeddedlabs.it
> Training, support and development for Windows CE
> (the reply address of this message is invalid)

Thanks Michel, Valter

So i the end it is just a matter to what base address the dll is
linked to...

Dean
Mon Apr 07 08:07:43 PDT 2008

Only for modules that are fixed up. Anything included at run time, or
included in the image in the FILES section is not fixed up, and can
therefore be loaded into either kernel or user space.

Also note that you don't have to be a driver to be loaded into kernel space.
An application can call LoadKernelLibrary() on *any* dll to put it into
kernel mode.

Bottom line, if you let me run on your CE6 device I can do anything I want.

--
Dean Ramsier - eMVP
BSQUARE Corporation


"Jack" <unseen_coder@hotmail.com> wrote in message
news:d3da58f1-1359-4f28-8bd0-7700f3f59d26@y21g2000hsf.googlegroups.com...
> On 4 Apr., 19:12, Valter Minute
> <v_a_l_t_e_r.m_i_n_u_t_e@g_m_a_i_l.com> wrote:
>> Jack <unseen_co...@hotmail.com> wrote in news:962fbaa9-bce3-41d9-a36e-
>> 4c1739c2d...@s50g2000hsb.googlegroups.com:
>>
>> > mike, thanks for the answer.
>>
>> > To make shure that i understand you correctly i try to repeat your
>> > post on my words:
>> > this mean that every driver which register itself under the HKLM
>> > \Drivers\BuiltIn will be loaded as KernelMode driver?
>>
>> > Well i thought that the kernel mode drivers (only the ones which are
>> > marked so in the *.bib file) are loaded by the kernel devicemanager
>> > dll which is loaded by the nk.exe in kernel mode.
>> > all other drivers are loaded by a udevice.exe in user mode.
>>
>> > did i got that concept wrong?
>>
>> The K flag is needed for modules that are part of the image and must
>> be fixed-up by makeimage to run in user or kernel mode (or both using
>> the "K." filename prefix trick).
>> If you load a DLL from a mass storage device it will be fixed-up at
>> runtime so it may run in user or in kernel mode.
>>
>> It should even not export the driver entry points (so not being a
>> driver at all) if it can do all it's "dirty work" inside its DllMain.
>>
>> --
>> Valter Minutewww.fortechembeddedlabs.it
>> Training, support and development for Windows CE
>> (the reply address of this message is invalid)
>
> Thanks Michel, Valter
>
> So i the end it is just a matter to what base address the dll is
> linked to...