How to set other threads to the alertable state

NTDEV
41

Pavel,

Actually, all the problems you have mentioned are solvable via account-level policies and restrictions that, compared to the third-party security software, are, probably, still more efficient and reliable. The problem is that Widows users tend to routinely run their machines as Admins. This is why they believe they need all these security tools ( that, btw, do not seem to solve the problems that you have mentioned either, do they).

When it comes to security in itself, I believe the most efficient approach to it is “security by isolation”, i.e. the one that allows multiple “personalities” on the same machine. Applying account-level policies is just a particular (and, apparently, the most primitive) form of this approach, but there may be the other ones with varying degrees of virtualization - from chroot and BSD jail-style sandbox to fully emulated machine with its own devices for every “personality” that you may assume…

Anton Bassov

42

> Please don’t tell such things. It is enough they totally ruined WM and made it useless, do you want

the same for ‘big’ Windows?

Actually, the idea in itself is not that bad - the main trick is to make it transparent to applications, i.e. make them believe that they run with root privileges on the machine while, in actuality, they may be restricted to a subset
of this machine…

Anton Bassov

43

> -----Original Message-----

From: xxxxx@lists.osr.com [mailto:bounce-447803-
xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Saturday, April 02, 2011 6:50 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to set other threads to the alertable state

Actually, the idea in itself is not that bad - the main trick is to make it
transparent to applications, i.e. make them believe that they run with root
privileges on the machine while, in actuality, they may be restricted to a
subset
of this machine…

The idea in itself may not be so bad but can you imagine its implementation by MS? I don’t want to switch to Linux :wink:

Michal

NOTE: The information in this message is intended for the personal and confidential use of the designated recipient(s) named above. To the extent the recipient(s) is/are bound by a non-disclosure agreement, or other agreement that contains an obligation of confidentiality, with AuthenTec, then this message and/or any attachments shall be considered confidential information and subject to the confidentiality terms of that agreement. If the reader of this message is not the intended recipient named above, you are notified that you have received this document in error, and any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this document in error, please delete the original message and notify the sender immediately.
Thank You!
AuthenTec, Inc. http://www.authentec.com/

44

>The idea in itself may not be so bad but can you imagine its implementation by MS?

I don’t want to switch to Linux :wink:

Seems to be the right time to move this discussion to NTTALK…

Anton Bassov

45

>

The problem is
that Widows users tend to routinely run their machines as Admins.
This is why
they believe they need all these security tools ( that, btw, do not
seem to
solve the problems that you have mentioned either, do they).

That’s a ‘users’ thing, not just a ‘windows users’ thing. People will
take the easiest way out, and when MYOB or whatever application doesn’t
work without admin privileges, guess what the easiest and fastest way to
resolve the problem is? It’s true under any operating system. Microsoft
had the right idea with the “cancel or allow” approach but too many
programs are sloppily written and require admin privileges so it just
becomes a nuisance not a saviour. And when you are an admin trying to
fix a machine and everything you do needs admin privileges it becomes
more than just a nuisance.

When it comes to security in itself, I believe the most efficient
approach to
it is “security by isolation”, i.e. the one that allows multiple
“personalities” on the same machine. Applying account-level policies
is just a
particular (and, apparently, the most primitive) form of this
approach, but
there may be the other ones with varying degrees of virtualization -
from
chroot and BSD jail-style sandbox to fully emulated machine with its
own
devices for every “personality” that you may assume…

That’s the approach taken by http://qubes-os.org/Home.html (which
doesn’t run Windows at this time), but as I think you are suggesting it
is just another layer on top of the per user and per process isolation
ideas that came before it - and it’s just another level of jail for the
malware to break out of.

James

46

> That’s a ‘users’ thing, not just a ‘windows users’ thing. People will take the easiest way out, and

when MYOB or whatever application doesn’t work without admin privileges, guess what
the easiest and fastest way to resolve the problem is?

Run the app as root, of course. However, it does not mean that you should log on as a root and run all your programs as the one, right? After all, this is what “RunAs” option is for…

It’s true under any operating system.

What makes Windows unique in this respect is that most programs assume root-level privileges, so that, as
you have pointed out yourself, it becomes just a nuisance - if you have to enter your Admin password every time you start a program it becomes quite annoying. Under the other OSes you have to do it once in a very while, because most programs don’t expect to have root-level privileges…

I think you are suggesting it is just another layer on top of the per user and per process isolation ideas
that came before it - and it’s just another level of jail for the malware to break out of.

What I am speaking about is a different approach to these old ideas - I am not suggesting building anything new on top of them. For example, consider a “one-to-one user/personatily/etc - VM” relationship implemented on top of microkernel.

Under this model, microkernel does nothing, apart from creating/destroying/scheduling runnable tasks upon guest kernel’s requests ( it can be made guest kernel’s responsibility to decide whether a given task is runnable, and to inform microkernel about the change of task’s state via a hypercall - microkernel can be left blissfully ignorant of guest’s synchronization/notification/scheduling internals), modifying address spaces upon guest kernel’s requests (again, all actual decisions are made by the guest), and abstracting the physical hardware. Every guest has its own “large” kernel with a filesystem, network stack and a view of hardware devices that can be either real or emulated. This “large” kernel is unprivileged code that communicates with microkernel via hypercalls

If, for some reason, you don’t trust some code, you can run it in one of these guests. The worst thing that it can do is to screw up this certain guest, but all other guests will remain intact. …

Anton Bassov

47

Application isolation should be the way to go. For example, Windows needs a concept of process-local window handles. Only the toplevel windows should have desktop-scoped handles.
An application need not have access to the whole SOFTWARE key (user or machine), write access anyway. And read access better be limited, too. It may be a good idea to redirect application’s registry access to its private “micro-registry” stored in its directory. This will help isolate the app even further.

Injection of remote threads or cross-process memory operations should only be allowed to vetted executables, or to processes inside the same application compartment.

And, finally, any new OS features SHOULD NOT be exposed to applications not specifically marked as built for the new OS version. Their look and feel should stay old style. At the same time, the applications marked for new OS version SHOULD NOT have any compatibility shims enabled. If you want new features, and look and feel - fix your old bugs.

48

@Alex Grig

I absolutely agree with that. I also don’t like the possibility to hook, inject, create threads and write on the memory of other processes in user mode. But at the moment we have no other possibility.

Access to other processes should be only possible in kernel mode. I searched for a solution to inject a DLL in kernel mode but most of you said that his is the wrong place to do this. In my opinion it is the right place. Modification of other processes should be only possible in kernel mode.

For me the second “user-mode-injection” code is much more dangerous as the first “kernel-mode-injection” code. A kernel mode injection can do only a signed driver but a user mode injection can be done by everyone.

If you think the concept to allow injection and write to other process memory only in kernel mode is not a good security concept please explain why.

regards
michi

49

@michele:

You don’t even need code injection. Check Task Scheduler APIs for requesting to execute code from a service to the logged on user session.

50

>

And read access better be limited, too. It may
be a good idea to redirect application’s registry access to its
private
“micro-registry” stored in its directory. This will help isolate the
app even
further.

Like a .ini file you mean? :slight_smile:

If every app was signed to prove identity, and could be assigned its own
‘user’ and ‘group’ then this could work even better. It would require
some rearchitecturing of the security system though… you’d almost need
two realms of permission - app permissions and user permissions, and
windows would need to check both before letting an app do something.
That way ‘game.exe’ could have different permissions to ‘cmd.exe’, even
though both are running as the same user.

Having fixed registry permission problems on previous occasions I think
I can safely say this could be a nightmare to fix when things go wrong
though.

James

51

Like an. Ini file…

Lol.

Indeed, the registry was supposed to save us from all our woes, kind of like
how sxs was going to save us from DLL hell.

Mm
On Apr 2, 2011 7:47 PM, “James Harper”
wrote:
>>
>> And read access better be limited, too. It may
>> be a good idea to redirect application’s registry access to its
> private
>> “micro-registry” stored in its directory. This will help isolate the
> app even
>> further.
>
> Like a .ini file you mean? :slight_smile:
>
> If every app was signed to prove identity, and could be assigned its own
> ‘user’ and ‘group’ then this could work even better. It would require
> some rearchitecturing of the security system though… you’d almost need
> two realms of permission - app permissions and user permissions, and
> windows would need to check both before letting an app do something.
> That way ‘game.exe’ could have different permissions to ‘cmd.exe’, even
> though both are running as the same user.
>
> Having fixed registry permission problems on previous occasions I think
> I can safely say this could be a nightmare to fix when things go wrong
> though.
>
> James
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other 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

52

On Fri, 01 Apr 2011 04:07:13 +0200, wrote:
> if(!(proc = GetProcAddress(kernel32,procname))) {
> apierror();
> return;
> }
> if(!(CreateRemoteThread(hProcId,NULL,0,proc,ipbase,0,NULL))) {
> apierror();
> return;
> }

Sorry for going on topic, but I’d personally feel uneasy about retrieving
the address of a system function in one process and then assuming it to be
the same in another one as this relies on an ASLR implementation detail
that might, however unlikely, change in future versions.

53

wrote in message news:xxxxx@ntdev…
> Pavel,
>
>
> Actually, all the problems you have mentioned are solvable via
> account-level policies and restrictions that, compared to the third-party
> security software, are, probably, still more efficient and reliable. The
> problem is that Widows users tend to routinely run their machines as
> Admins. This is why they believe they need all these security tools (
> that, btw, do not seem to solve the problems that you have mentioned
> either, do they).
>
>
> When it comes to security in itself, I believe the most efficient approach
> to it is “security by isolation”, i.e. the one that allows multiple
> “personalities” on the same machine. Applying account-level policies is
> just a particular (and, apparently, the most primitive) form of this
> approach, but there may be the other ones with varying degrees of
> virtualization - from chroot and BSD jail-style sandbox to fully emulated
> machine with its own devices for every “personality” that you may
> assume…
>
> Anton Bassov

Anton, I agree that many of these issues likely can be solved by
account-level policies.
But - there are so many “security tools” and people keep asking for more.
One thing is sure here: even if the OS has these capabilities, users and IT
are unable to use them as is.

My point was that IT of certain org may be willing to trade some OS features
for more security/compliance/whatever,
and they are responsible to solve resulting interop issues.

So… if the OP’s software is for a “managed” environment, they likely will
test it and any nasties will be attributed to him :slight_smile:
/* Compared to what Mr. Russinovich wrote about recently, APCs look pretty
innocent. */

For home or small business users this tradeoff may be not possible, because
they cannot handle arising issues themselves.
Third party “security” vendors are like vendors of any other drugs,
customers should not take their ads for 100% truth…

–pa

54

@Cay Bremer

Yes, this simple dll injection source code sample has several issues and need some modifications. This is not a ready to use source code sample.

  1. The address calculation
    It is necessary to get the kernel32.dll module base address of the calling and the target process.
    The difference (delta value) of this two module addresses must be added to the target method address.

  2. Then sample doesn’t free the handles and memory.
    First it is necessary to wait until the thread has done its loading operation.
    We can just use WaitForSingleObject(hThread, time); and then we can close the handles and free the memory with VirtualFreeEx.

regards
michi

55

>session. Shared components are still causing DLL hell.

Worse so, DLL hell was recently replaced with SxS hell, which is much worse.

Microsoft needs to follow iOS example by vetting and sandboxing the apps

…and then lose their absolutely dominant desktop/server market share to some Android (probably even to the direct desktop Android version).

Lack of restrictions in Windows is what makes it the dominant desktop/server OS, and still a dominant laptop one (except the most expensive segment).

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

56

> Lack of restrictions in Windows is what makes it the dominant desktop/server OS, and still

a dominant laptop one (except the most expensive segment).

IIRC, not so long ago someone was claiming that “people love policies applied to them” and insisted that restrictions are the key to Apple’s success on the market. Now there is a complete U-turn of opinion. Bizarre…

Anton Bassov

57

>IIRC, not so long ago someone was claiming that "people love policies applied to

them" and insisted that restrictions are the key to Apple’s success on the
market. Now there is a complete U-turn of opinion.

It was me. – pa

58

> It was me

No, it was Max - you can check http://www.osronline.com/showThread.cfm?link=192235 ( post 41 - it is a long rambling thread with 141 post on it)…

Anton Bassov

59

> If you think the concept to allow injection and write to other process memory only in kernel mode is not a good security concept please explain why.

Because there is no security boundary between two processes running as the same user. Preventing one such process from injecting threads or modifying memory of another such process would not increase security in any meaningful way. It would however make it impossible for users to debug their own processes without installing a kernel driver first. Installing a driver requires administrator rights, and it’s not a good idea to require administrator rights for a task which does not really need them (like debugging one of your own processes).

From another angle, imagine if Visual Studio and other similar products had to ship their own driver to enable cross-process debugging. Would you rather trust them to get access checks, parameter probing etc. right (so they don’t introduce a security hole), or use a well-tested OS-provided API instead (WriteProcessMemory)?

Thanks,
Pavel

60

> Because there is no security boundary between two processes running as
the

same user. Preventing one such process from injecting threads or
modifying
memory of another such process would not increase security in any
meaningful
way. It would however make it impossible for users to debug their own
processes without installing a kernel driver first. Installing a
driver
requires administrator rights, and it’s not a good idea to require
administrator rights for a task which does not really need them (like
debugging one of your own processes).

From another angle, imagine if Visual Studio and other similar
products had to
ship their own driver to enable cross-process debugging. Would you
rather
trust them to get access checks, parameter probing etc. right (so they
don’t
introduce a security hole), or use a well-tested OS-provided API
instead
(WriteProcessMemory)?

My kids doing word processing and surfing the internet on their little
laptops at home don’t need to debug their own or anyone elses processes
though (at least not yet :slight_smile: so if such isolation made their processes
safer from malware and other nasties then bring it on. I’ll turn off
such isolation on my PC when I need to do debugging etc, fully
understanding the risks.

James