In 32-bit system, So we can intercept with the SSDT function properly and prevent other processes into the process, but under 64-bit systems there is PatchGuard, So we can not simply deal with, but if by a special way to disalbe PatchGuard, although you can reach the goal, but this method, in fact, put the security of the system is reduced, so I was looking for a way non-disable PatchGuard in the premise, by driving the process to prevent other processes into their own way, of you have any suggestions? any suggestions or opinions are very grateful. Thank you,
Under the existing Windows security model opening a handle to a kernel object allows you to perform all actions that the rights associated with a given handle imply. These rights are normally defined on user basis.
A handle to a process that runs under the same user account gives a handle holder the right to perform any action on the target process that it can perform on itself, which includes allocating/deallocating/modifying memory in the target process’s address space, creating/destroying/suspending/resuming threads, as well as terminating the process itself.
This is what Windows security model is about. What you are trying to do is, basically, an attempt to circumvent this model. As Mr.Burn would say in such case, “your product will be branded as MALWARE…” and so on and so forth if you attempt to do something like that. The bottom line - just give it up…
What truly amazes me is that you are asking such a question after having been posting here for more than 3 years(!!!)…
What truly amazes me is that you are asking such a question after having been posting here for more than 3 years(!!!)…
And what? Has Windows security made a huge progress in these 3 years?
Customers are always right; if they are not happy, they keep looking around.
– pa
> And what? Has Windows security made a huge progress in these 3 years?
Not at all…
However, I think an issue like that had been discussed countless times in this NG in the last 3 years, so that the OP should know in advance what kind of answers he may get…
Customers are always right; if they are not happy, they keep looking around.
True…
This is what feasibility studies are for - you just present a customer with the analysis so that he/she knows
pros and cons of every possible strategy. At this point you can already discuss the terms of a particular contract, and decide what kind of obligations you are willing to take in it f they insist on some feature that just turns the system upside down and contradicts the very logic of good design (something like displaying MsgBox from a driver because they don’t want to have any additional UM components)…
> And what? Has Windows security made a huge progress in these 3 years?
Not at all…
However, I think an issue like that had been discussed countless times in this NG in the last 3 years, so that the OP should know in advance what kind of answers he may get…
I had one particular customer for 6+ years now. Every 6 months they keep asking “How do we prevent a copy, but allow read?”. For them, the fact that 6 months have passed seems to mean that the laws of physics have changed and that some new law will allow for what they want And I have already told them 10 times now that it will never be possible. They kept and keep asking the very same question.
> Customers are always right; if they are not happy, they keep looking around.
True…
This is what feasibility studies are for - you just present a customer with the analysis so that he/she knows
pros and cons of every possible strategy. At this point you can already discuss the terms of a particular contract, and decide what kind of obligations you are willing to take in it f they insist on some feature that just turns the system upside down and contradicts the very logic of good design (something like displaying MsgBox from a driver because they don’t want to have any additional UM components)…
You would be surprised how many of the world’s largest IT companies are willing to accept abnormal (for a lack of better word here) design just to get to their goal. Some of them have ridiculous user administrator (from secretaries and cleaners with complete Administrator rights to setups where no security is even present, AV included), and yet they want SUCH setups to be brought into the 21st century.
“I had one particular customer for 6+ years now. Every 6 months they keep
asking “How do we prevent a copy, but allow read?”.”
Consider yourself lucky they are still your customer. They could have gone to some goddamned hack (we’ve seen some posting on ntdev), who would have promised a solution and then hacked a horrible kludge that would appear to work.
There is a concept of properly configured system. Unfortunately, Microsoft can’t find testicular fortitude to force the users to use proper configuration.
REPEAT ALOUD: DON’T GIVE USERS ADMINISTRATIVE PRIVILEGES.
If you want a process that nobody could mess with, run it under secure account (LocalService, for example).
“I had one particular customer for 6+ years now. Every 6 months they keep
asking “How do we prevent a copy, but allow read?”.”
Consider yourself lucky they are still your customer. They could have gone to some goddamned hack (we’ve seen some posting on ntdev), who would have promised a solution and then hacked a horrible kludge that would appear to work.
In 32-bit system, So we can intercept with the SSDT function properly
*****
there’s a serious question as to whether it could possibly make sense to
say that patching the SSDT is EVER “proper”
******
and
prevent other processes into the process,
******
I can’t even parse this sentence. Do you perhaps mean “I can wreak some
horrible kludge by which I can deny one process the right to access
another process created by the same user”? If so, say this. Then don’t be
surprised when the security hole you used to effect this kludge is fixed.
What part of “undocumented interface” have you failed to grasp?
You might look into Integrity Levels for Vista and beyond.
******
but under 64-bit systems there
is PatchGuard, So we can not simply deal with, but if by a special way to
disalbe PatchGuard, although you can reach the goal, but this method, in
fact, put the security of the system is reduced, so I was looking for a
way non-disable PatchGuard in the premise, by driving the process to
prevent other processes into their own way, of you have any suggestions?
any suggestions or opinions are very grateful. Thank you,
*****
This sounds like the question, “We did a very bad design, then exploited
a malware security hole to compensate for our bad design, and now that
system security is better, our lame fix for our bad design no longer
works, so can we re-compromise security so we don’t have to fix our bad
design?”. Did I get the question right?
*****
Thank you anton bassov,Dejan Maksimovic,Alex Grig and Joseph M.
I think I need to say under my goal.
My goal is to ensure by some means I have to run security software, including but not limited to injection of malicious software, For example, We can inject a process by CreateRemoteThread, SetWindowsHookEx and other means, It looks a legal means, but for me, this is unsafe, so now I have to do is to stop these behaviors into my program because my program needs to ensure your safety during operation is not used by other malicious software or damaged.
Yes, you may say, This is my software which has vulnerabilities, of course, you right, all of the software is flawed, Microsoft’s Windows is no exception, Is it not so?
> I think I need to say under my goal. My goal is to ensure by some means I have to run security
software, including but not limited to injection of malicious software, For example, We can inject
a process by CreateRemoteThread, SetWindowsHookEx and other means, It looks a legal means,
but for me, this is unsafe, so now I have to do is to stop these behaviors into my program
because my program needs to ensure your safety during operation is not used by other malicious
software or damaged.
Go and read my posts again - this is the example of a goal that is unrealistic in itself, because it contradicts the very basic principles of Windows security (i.e. that all processes running under the same user account are equal). Surely this unrealistic goal has solutions, but they will all be unstable, plus add system-level instability like interops. You already had a chance to see it with your own eyes - your solution got broken by the PatchGuard…
>> REPEAT ALOUD: DON’T GIVE USERS ADMINISTRATIVE PRIVILEGES.
…which, in practical terms, means " make a good half of all their programs
unusable"…
Um…no. My XP laptop on work was configured this way, and saved my butt a few times. Everything worked. Had to adjust permissions on DDK/WDK directory, though. All my home installations from Win2000 to Win7 has been configured this way (and saved my butt a few times, too), and most programs worked, except for a few retarded ones, like ICQ circa 2000.
“My goal is to ensure by some means I have to run security software, including
but not limited to injection of malicious software”
The proper way to do that is to run it in more privileged account (LOCAL_SERVICE or LOCAL_SYSTEM). In Vista+ you can run it on higher integrity level instead.
> Um…no. My XP laptop on work was configured this way, and saved my butt a few times.
Everything worked. Had to adjust permissions on DDK/WDK directory, though. All my home
installations from Win2000 to Win7 has been configured this way (and saved my butt a few times, too),
and most programs worked, except for a few retarded ones, like ICQ circa 2000.
Basically, what you are saying is “my system mostly worked”, which is hardly satisfactory if such configuration is made compulsory , don’t you think…
BTW, when I was using Windows I was always browsing the web only under the guest account.
In my experience, the implied security “mostly worked” - indeed, “my butt was saved few times”, in your terms, but, despite that, I was still getting infected almost on regular basis…
Therefore, the “solution” that you offer is not that reliable either (at least not in the Windows world), although it is certainly helpful…
“but, despite that, I was still getting infected almost on regular basis…”
Are you implying guest account had enough privileges to infect your system?
By the way, in Vista+, IE runs restricted, so it can’t even write files to your user directory, unless explicitly allowed. For example, its Save As dialog token doesn’t even have rights to delete files.
wrote in message news:xxxxx@ntdev… > “but, despite that, I was still getting infected almost on regular > basis…” > > Are you implying guest account had enough privileges to infect your > system? > > By the way, in Vista+, IE runs restricted, so it can’t even write files to > your user directory, unless explicitly allowed. For example, its Save As > dialog token doesn’t even have rights to delete files.
By the way, “remote execution” WU patches keep coming every month. – pa
“but, despite that, I was still getting infected almost on regular
basis…”
Are you implying guest account had enough privileges to infect your
system?
The word on the street is that there are enough privilege escalation
exploits in Windows that denying users admin privileges is not a barrier
to infection. I’m not sure if that’s as true as it once was but it’s the
reason a lot of people give for just giving everyone Admin privileges,
and given the delay between a 0day vulnerability becoming public and
Microsoft releasing a fix[1], they may have a point[2].
James
[1] This isn’t really pointing the finger at Microsoft - they can
probably come up with a fix in an hour once they have a copy of the
exploit, but the testing required to ensure that the fix doesn’t
introduce regressions adds a delay of at least a few days which is
plenty long enough for the bad guys to react.
[2] while at the same time missing the point that an unprivileged user
can’t go and delete comctl32.dll because a friend told them it was a
virus.
Well one of the largest set of exploits available are two well known
anti-virus products who left the barn door open. Of course both of
these companies left the barn door open by HOOKING! But I’m sure the
OP will do better, oh well if you believe that there is a lot of emails
on business opportunities I will forward you from Nigeria.
> > > > “but, despite that, I was still getting infected almost on regular > basis…” > > > > Are you implying guest account had enough privileges to infect your > system? > > > > The word on the street is that there are enough privilege escalation > exploits in Windows that denying users admin privileges is not a barrier > to infection. I’m not sure if that’s as true as it once was but it’s the > reason a lot of people give for just giving everyone Admin privileges, > and given the delay between a 0day vulnerability becoming public and > Microsoft releasing a fix[1], they may have a point[2]. > > James > > [1] This isn’t really pointing the finger at Microsoft - they can > probably come up with a fix in an hour once they have a copy of the > exploit, but the testing required to ensure that the fix doesn’t > introduce regressions adds a delay of at least a few days which is > plenty long enough for the bad guys to react. > > [2] while at the same time missing the point that an unprivileged user > can’t go and delete comctl32.dll because a friend told them it was a > virus.
And I have already told them 10 times now that it will never be possible. They kept and keep asking the very same question.