The Old New Thing

So, aside from creating a huge, gapping security issue, does ReadProcessMemory serve any legimate uses?

Way back in the day, when I first started reading about the abilities of the 286, I was excited about the memory manager protecting processes from intrusion (such a step up from the constant guru meditation errors on the AMIGA, which lacked such protections).  I'm disappointed that over time, it has been so poorly evolved.

I gotta go with other, more FUD inspired individuals when them claim insecurity was built in from the ground up when I read things like this.

> (Besides, if the user hibernates the

> computer, all the pages that aren't in the

> page file are going to get written to the

> hibernation file, so they'll end up on disk

> one way or another.)

[snip]

> The encryption keys used by these functions

> are generated pseudo-randomly at boot time

> and are kept in kernel mode. (Therefore,

> nobody can ReadProcessMemory them, and they

> won't get captured by a user-mode crash

> dump.)

If the user hibernates the computer, the encryption keys would get written to the hibernation file, too, wouldn't they?

Xepol:

One (IMHO) legitimate use of ReadProcessMemory I found a long time ago was in the WinAmp remote API. You could send the WinAmp window some message, and get a pointer to a text string of the current song title returned, but of course that title was in WinAmp's memory space, so you had to ReadProcessMemory to access it. Actually that interface was only intended for in-process plugins, but it worked just as well for other processes.

>> So, aside from creating a huge, gapping security issue, does ReadProcessMemory serve any legimate uses?

Debugging. Benign code injection (powermenu and alikes). Really I feel bad about the opposite. Why is a process running on MY computer actively hiding informations from me ? (I know the answer, sadly).

Besides, if you want to read the memory of a process you can simply virtualize. Or sniff bytes travelling on the bus using electronic equipment.

I believe that the primary purpose for ReadProcessMemory is debugging. How would you write a debugger without it?

ReadProcessMemory isn't that much of a security hole - to use it, you have to be on the right side of the airlock, and be able to run code that executes with sufficient rights. For example, user Bob can read memory in his own processes - or he could just look at the text printed on the screen - but user Alice can not - and if she can, then there's already a problem. The ReadProcessMemory function just means it can be done correctly, rather than having a thousand ad-hoc incomplete attempts at implementing it for legitimate purposes.

And I don't care what the memory manager folks or their documentation says about what will happen "in practise" - unless there's a specific promise that calling a function will prevent the block of memory ever being written to disk, then the fact that currently it won't be written to the pagefile doesn't prevent the next version of Windows doing something different, but the official "lock memory so it can't be paged ever" API, on the other hand, is offering an actual guarantee.

How many problems have we seen caused by people doing what works "in practise" even when the documentation says otherwise and then people have howled when the API is updated to enforce the documented rules?

VirtualLock does not promise to keep your data out of the page file, so relying on a current implementation detail is asking for trouble.

With the risk of pointing out the obvious, ReadProcessMemory works only on your processes (unless you're root or Admin) Other operating systems have similar facilities, so Windows is no less secure than the rest in this regard.

I figured out in the next-to-last paragraph that this blog entry was about people who want to avoid memory blocks being paged out to protect sensitive data.  Isn't that pretty  rare? What I see more in my field is people trying to lock large blocks in RAM for performance reason, for example in image processing or games, or some hardware interaction, including locking buffers for DMA transfer to GPU.  

IMHO this is one of those articles article that will make these loose-cannon programmers that surround us try to use some work-around, in this case AWE functions, for a problem that they think there is with the correct API.  This article has all the facts, and I get it, but I think casts fear that VirtualLock doesn't work if you read it in diagonal. A proper title like 'Preventing sensitive data from getting the page file' would have been my choice. Might be also more search engine friendly.

> Tuesday, November 06, 2007 2:53 PM by Anony Moose

ReadProcessMemory isn't that much of a security hole - to use it, you have to be on the right side of the airlock, and be able to run code that executes with sufficient rights.

To use ReadProcessMemory, you need to have a handle a process with the PROCESS_VM_READ bit set. I do not believe that is a security hole; but I do believe it's a security hole that this capability is available to processes that aren't debuggers.

Xepol: I don't think you understand the point here.  As others have also pointed out, there are other ways of getting the information as well as legit uses.  Raymond also pointed out reasonable alternatives if you're thinking VirtualLock as a security mechanism; it is more of a performance tool, not a true security mechanism.

The WDM/WDK/DDK provides several functions to pin user buffers to memory. Page faults at the kernel level are pretty much always a BSOD, IIRC, so there needs to be a way to pin it. That's in addition to the NPP.

Sorry - off topic.

@Xepol: The 68000 through 68030 CPUs don't have a(n) MMU (not sure about the 68030, actually,) so it wasn't as much an OS issue as a hardware issue. Things were different for the A4000 with its 68040 CPU.

*waxes nostalgic* I kinda miss my A4000.

The problem on the Amiga was that every program shared the same address space and memory. If a program went haywire it could corrupt the memory of every other program and, if I remember correctly, even the kernel.

The problem wasn't security, it was stability. When things crashed badly on the Amiga the entire computer would crash out and have to be rebooted.

Programs on Windows can do some of those things to each other but they have to do it *on purpose* which is a big difference.

I was a bit surprised to find out that on Vista you don't need a UAC prompt or admin rights to debug another process (that is running at the same level as you) but if you think things through there would not be much to gain from restricting debug APIs to admin processes. Win32 provides many ways to inject code into other processes (e.g. message hooks which serve a legitimate purpose) so the debug APIs by themselves don't matter that much, IMO.

If debug APIs required admin rights then authors of third-party debuggers would have to write applications that required admin rights - and this would introduce the possibility of elevation of priviledge attacks.

The current scheme means that data that is available to a user is accessable to that user, and only that user - and noone is making promises of security that can't be met.

(Ok, its not a very likely opportunity - but every application that requires admin rights when it doesn't need to is just making life more difficult. And it would mean developers would spend more time typing in their password than they'ld spend coding - or, perhaps, they might work around that by disabling checks for elevation of priviledge, which would be a great benefit to the spyware community.)

If you can run code in a user's context then either you use ReadProcessMemory and have to have a deep knowledge of the data structures being used, or you can just read the same files off the disk and do whatever you want with them. By the time that ReadProcessMemory is any form of risk, it's too late to worry.

While the point for debuggers has some validity, I don't think that the ability to hack into another application is a feature so much as a less dangerous intrusion that is possible.  I suspect that these "legitimate' methods could be addressed another way by the OS if there was a desire to do so.  As it is, people are hacking around the OS, whether it is for good or ill.  

I suspect that there has to be a better solution that letting processes peer into each other's memory.  Full isolation, while inconvenient for some eye-candy features, would probably provide much greater security.

And does every computer need to be able to act as a ring 3 debugger?  I seriously doubt it.  The OS could continue to do ring 0 debugging for crash log purposes, and act as a proxy for other debugger apps, say if a physical switch was thrown (and default to off). It can be possible to be MORE secure rather than less.

I got the idea from that sentence about hibernation people would like to prevent their process' memory from written to disk even in that case. :)

"What I see more in my field is people trying to lock large blocks in RAM for performance reason, for example in image processing or games..."

It seems these functions work well for performance optimizations. If the system is under such memory pressure that the Mem Manager is forced to page out VirtualLocked() memory, then the user should get more RAM or kill some processes.

(Though I do wish there is some way to better control the Mem/Cache Manager, e.g., limit the system cache size. Eagerly awaiting Vista SP1 for that capability. But anyway, VirtualLocked memory won't be used for caching, right?)

"...or some hardware interaction, including locking buffers for DMA transfer to GPU."

On the other hand, if locked memory is required for correctness (concurrent hardware access), then you had better be doing that from kernel mode anyways. Doesn't DirectX and the video driver handle that for you?

VirtualLock() is very usefull. You can use it to lock some frequently used buffer in memory so you don't get page faults and TLB misses on it.

Another thing to note, VirtualLock() will fail if you attempt to lock more memory than your working set size allows. To be able to lock large chunks of memory you need to increase your process working set size first.

As for ReadProcessMemory() why bother when you can already inject the thread into the target process easily which not only can read memory but also execute in security context of the target?

Last time I checked there was also a nice backdoor called NtSystemDebugControl() which allows for all sorts of things like read/write CPU MSR registers (which alone is enough to give you ring 0 access), bang over I/O ports and CMOS, and even read/write arbitrary memory.

> You can use it to lock some frequently used buffer in memory

If it's "frequently used" then you don't need to VirtualLock it -- it'll already be in memory. You use VirtualLock for INfrequently accessed memory that you don't want paged out.

Xepol: Don't forgot, ReadProcessMemory only works for processes that you already own (unless you're an administrator).

Tuesday, November 06, 2007 11:32 PM by Dean Harding

Xepol: Don't forgot, ReadProcessMemory only works for processes that you already own (unless you're an administrator).

Then it's assuming that you want to allow every process you run to be allowed to do whatever it wants to every other process you run. If 100% of all code was trustworthy, there wouldn't be a need for security at all, would there?

[Watch my l33t h4x0r skillz:

L33tReadProcessMemory()

{

AttachAsDebugger(dwTarget);

ReadProcessMemory();

DetachAsDebugger(dwTarget);

}.

P0wnd! -Raymond]

Leetness not withstanding, can you link me to the msdn article for Attach/DetachAsDebugger?

(PS: Only scriptkiddies say p0wnd)

Triangle: Here's the MSDN article that says how to debug a running process: http://msdn2.microsoft.com/en-us/library/ms679301.aspx

"Leetness not withstanding, can you link me to the msdn article for Attach/DetachAsDebugger?"

I think the point was not so much that there are functions called (Attach|Detach)AsDebugger as it was that if only debuggers were able to read the memory of other process, all malware would have to do is act like a debugger.

For all you people complaining about the presence of ReadProcessMemory and probably thinking how superior $YOUR_FAVORITE_OS is because, after all, the presence of ReadProcessMemory is a broken-by-design gaping security hole that illustrates how "insecurity was built in from the ground up", how does that differ from ptrace(PTRACE_PEEKTEXT, pid, ...) on Linux, ptrace(PT_IO, pid, ...) on BSD, ptrace(1, pid, ...) on SunOS, etc., or the newer procfs debugging mechanisms?

[This is half a facetious question and half real. It's possible that there are differences, but seeing as I can debug another of my processes from user space on Unix, I kinda doubt it.]

Everyone seems to be off saying ReadProcessMemory is a huge security flaw, and that it should only be restricted to debuggers.

(I'm surprised Raymond hasn't brought it up)

Question - what's a debugger (how do we define one?)? How can we define some random EXE as a "debugger"? The way you define it must satisfy a few properties like anyone must be able to write their own debugger (and test it), that some smart person can't set some magic "PROCESS_IS_DEBUGGER" flag, and that there's no bottleneck in whatever process you implement?

If I write an app, and decide to store some information that could be useful for the end user to provide me in case they need support, a  memory block would be ideal. Shared memory won't work (only one instance allowed, or lock management issues) since the former may be no doable, and the latter has performance issues if the app accesses it repeatedly. However, a chunk to which I could blindly write to (it's my own private memory), and if needed, I can create my own debug app that uses ReadProcessMemory to read this memory block and provide useful debugging and support information. Little impact to 99% usage (just extra memory writes), but also means I don't log everything to disk, or distribute a special debug version, yet offers me a good peek inside when I need to.

Worf: Raymond did talk about it, see http://blogs.msdn.com/oldnewthing/archive/2006/05/10/594537.aspx.

Basically, every process you run is allowed to do anything you can do, no exceptions.

Per your "follow-up" it appears that not only are you a self-important douchesack -- well established prior to this day -- but are a misinformed self-important douchesack.  

This is the only time in my memory that you addressed an error on this blog without adding some snarkily critical commentary.  In the future, please consider your own shortcomings before you criticize others for theirs.

Evan:  the difference is that in those other OSes the typical user account does not have administrator privileges, contra Windows (at least < Vista).

Why not use the GMEM_NODISCARD flag to make the memory unswappable?

Sorry - more off topic:

"@Xepol: The 68000 through 68030 CPUs don't have a(n) MMU (not sure about the 68030, actually,)"

The 030 actually did have an MMU. The 020 could be fitted with an external MMU, somewhat like an external math coprocessor chip. The original Macintosh II (020) actually had a socket for an optional MMU. This socket was normally populated with a pass through chip that did some kind of rudimentary 24/32 bit address mapping, somewhat similar to the PC's A20 issue.  Apparantly, some early Macintosh software liked to use the Most signficant 8 bits of a 32-bit address as flag bits, which caused trouble when you actually had 32 address lines.

I believe it was necessary to install the external MMU for A/UX (Apple Unix) as well as virtual memory under System 7. The Macintosh IIx and SE/30 eliminated this complexity by switching to the 68030.

Dean Harding said : "If it's "frequently used" then you don't need to VirtualLock it -- it'll already be in memory. You use VirtualLock for INfrequently accessed memory that you don't want paged out."

Under heavy memory load even frequently used buffer can be flushed out.

"Evan:  the difference is that in those other OSes the typical user account does not have administrator privileges, contra Windows (at least < Vista)."

Then why hasn't this been clearly said before in the thread, and why are people complaining about ReadProcessMemory instead?

"[Administrator privileges is irrelevant. Or are you saying that on unix only administrators can run a debugger? Do programmers have to run as root? -Raymond]"

Not sure if this is meant sarcastically or not, but you don't need to be root. You can attach to existing processes (of your own... I think typically ones that belong to the same session, though that goes beyond the level of detail I know) and read their memory, same as on Windows.

And in case that's not enough for you, if you're admin you can always just read /dev/mem.

Igor, are you referring to this CreateRemoteThread (http://msdn2.microsoft.com/en-us/library/ms682437.aspx)? Because if you are, it must be someone else's invention as CreateRemoteThread requires PROCESS_CREATE_THREAD, PROCESS_QUERY_INFORMATION, PROCESS_VM_OPERATION, PROCESS_VM_WRITE, and PROCESS_VM_READ (some of the same rights as ReadProcessMemory and many more) written in the sacred MSDN here (http://msdn2.microsoft.com/en-us/library/ms684880.aspx).

Yes, Raymond, your logic was right.  And since other OSes don't require administrative privileges to use a debugger, the only conclusion we can draw is that either (a) allowing non-admins to ReadProcessMemory actually isn't a security hole, or (b) debuggers don't actually need the equivalent of ReadProcessMemory.

Since ptrace *is* the equivalent of ReadProcessMemory (plus a whole bunch of other things), and is allowed on *nix under the same set of conditions that ReadProcessMemory is allowed on Windows (target process has to be running under the same user, or the user has to be an admin), we can discard (b).

Therefore, ReadProcessMemory isn't much of a security hole.  Or if it is, other OSes do have it as well.

(Remember, people, security is implemented per user, *not* per program.  If you want to do security per-program, then you need to run each program under a different account.)

For what it's worth, Singularity implements per-program security. Since programs are fully specified by the metadata in their assemblies and processes are immutable (no reflection in Singularity: to have dynamic code you must compile it into a new program, run it and interact through IPC), it logically follows that programs can be principals to the security subsystem, rather than just some instance of an user account.

Due to things like LoadLibrary, Read/WriteProcessMemory, due to the fact that the CPU, heck, _any_ VonNeumann machine lets you load arbitrary code at any time, Windows programs are not by themselves immutable identifiers (token objects are. That's why they are the principals). You'll see various hacks that try to make them so (e.g. some personal firewalls, Microsoft's own Safer), but it's just not what they are

KJL::Hyperion: LoadLibrary, Write/Read processMemory are all layered way above the CPUs' level. Per process security is certainly enforcable on current CPUs. Just nobody does it.

Personally, I'm just confused about the "If you have relatively small chunks of sensitive data, the solution I've seen recommended is to use CryptProtectData and CryptUnprotectData."  Is the recommendation being cited to give an example of a bad solution?

>> Per process security is certainly enforcable on current CPUs. Just nobody does it.

I will begin to consider computer security something interesting and well implemented when processes will have different permissions even on minor operations. "Why that download manager is trying to open my address book ? Denied! Why that IM app is deleting a picture file ? DEEENIEEEED!"

User based security in the era of personal workstations is not so useful. So if an app goes south in [ANY OS HERE] and I'm not root/admin it can ONLY delete my files ? Seems like a car TV spot saying "The engine keeps working even after a crash! Only people inside would die! Isn't it great ?".

Acutally, it's more like a car TV spot saying "The engine keeps working, and all the other passengers are guaranteed to survive after a crash. Only the driver who is responsible for actually crashing the car would die! Isn't it great."

And, yes, that would be great. Insulating everyone else from the folly or bad luck of one person is a great practice to follow if you can.

Alternatively, you could change the emphasis in your other sentence to "it can only delete MY files?". Yup, all the files belonging to your cow-orkers, family members, housemates, etc... (assuming they have their own non-admin accounts, which they should, even if only for conveniences like having their own bookmarks, address books, email accounts, etc...) will be fine.

On top of that, if the OS files (which are not "your" files) are safe and intact, it makes restoring from backup a lot easier. Compared with being hosed as an Administrator where you have to restore the OS and apps before you can think about getting your backups, that's a great advantage.

Kuwanger wrote:

Personally, I'm just confused about the "If you have relatively small chunks of sensitive data, the solution I've seen recommended is to use CryptProtectData and CryptUnprotectData."  Is the recommendation being cited to give an example of a bad solution?

[I added that because if I didn't say anything, people would complain, "No fair telling us what not to do without telling us what we should do." And then when I do add the information, people get confused. So it's either complaints or confusion. I think I was better off with complaints. -Raymond]

This is a "no middle ground" argument, and you should be ashamed.  You 'added the information', but you did not actually advise people what do to, you reported second hand advice.

Grow up and stop whining like a baby.

>> And, yes, that would be great. Insulating everyone else from the folly or bad luck of one person is a great practice to follow if you can.

Except that most of the cars only have the driver in it.

>> Alternatively, you could change the emphasis in your other sentence to "it can only delete MY files?". Yup, all the files belonging to your cow-orkers, family members, housemates, etc... (assuming they have their own non-admin accounts, which they should, even if only for conveniences like having their own bookmarks, address books, email accounts, etc...) will be fine.

Never seen a multiuser system which isn't also a terminal server. Every single workstation I've seen is used by a single user. The only case I've seen apart from it is family PCs but usually all users share the same account for a number of reasons (not last being idle).

>> On top of that, if the OS files (which are not "your" files) are safe and intact, it makes restoring from backup a lot easier. Compared with being hosed as an Administrator where you have to restore the OS and apps before you can think about getting your backups, that's a great advantage.

You know the OS files are the only ones you know to have a backup for sure. The inconvenience is very minor, compared to "find the backup", "hoping it exists", "hoping it's readable" and so on.

I really prefer the machine to smoke out, auto destroy itself but present me a safe harddisk with my data intact in it. Everything else is something I can buy. Even time (I want my machine setup faster ? Buy a new one preinstalled. I want my wedding photos back ? no chance).

[I gave the best information I had. Sorry that wasn't good enough for you. Maybe you were expecting something authoritative? Sorry, this blog is not authoritative. You should know that by now. -Raymond]

I know that.  The original poster might not.  Why not tell him calmly, instead of throwing all your toys out the pram?

It doesn't need to be a nitpick-corner-like-thing (I hate those); a friendly "sorry X, I just picked that example randomly.  This is not the authoritative way to do it - I leave finding that as an excercise for the reader.  (I don't know.)"

@..

"I will begin to consider computer security something interesting and well implemented when processes will have different permissions even on minor operations. "Why that download manager is trying to open my address book ? Denied! Why that IM app is deleting a picture file ? DEEENIEEEED!""

The problem here is that I'm not convinced there is a good way to do this. How does the OS know that the download manager shouldn't be able to open your address book, but your mailer should? They are both just processes to it, ruing a specific image.

I can only think of a few ways to implement fine-grained controls, and they all suck:

1. Make the user specify it for each program. Most people won't do it.

2. Have something so the first time a program tries to open your address book, prompt the user. Sucks because it's really really obnoxious, and you shouldn't ask people questions they don't know how to answer.

3. Programs come with the permissions they should have. May help with programs with plugin architectures (X says that it shouldn't open your address book, but malicious plugin Y is trying to), but most malware will just come with all the permissions set.

4. Trust the OS vendor to say what programs should be able to do what. Sucks because new programs, or new builds of programs, are screwed, and because you may not *want* to trust the OS vendor for that.

5. Trust a third party to say what programs should be able to do what. Sucks for the same reasons as #4.

6. A slightly more reasonable alternative is to do some combination. For instance, follow #2 if a program is signed, but #1 if not. Or follow #4 if a program is in the database, but #1 if not. But it's still obnoxious when it reverts to #1 (or even worse, when it just default denies).

The only approach that seems potentially reasonable (at least until computers can read your mind) is some sort of learning thing, where the OS learns what permissions your software should have. But then what happens for something new?

I don't know if there is a way to do that which works well enough. It may just be easier to live with the problems that come from systems that are more insecure. Remember, there is nothing inherently wrong about being insecure; the problem with it is that it can cost you later (in time, money, etc.). If the costs of "fixing" the problem are higher than the costs of the problem, then it's probably not worth doing.

@.. (in a later post)

"Except that most of the cars only have the driver in it."

But most cars aren't the only ones on the road, which means that other drivers aren't insulated.

'[I added that because if I didn't say anything, people would complain, "No fair telling us what not to do without telling us what we should do."'

Except you didn't tell us what we should do.  You told us what someone else told us we should do.

'And then when I do add the information, people get confused. So it's either complaints or confusion. I think I was better off with complaints. -Raymond]'

Yes, I was confused because as others pointed out, the "solution" is just a step in obfuscation.  And passing off the bad advice/information of others, even if it's non-authoritative, doesn't seem like the best thing to do; even while not being under the authoritative cloud of "Microsoft employee", people do hold you to some authority as "general computer programmer guy" either spreading a rumor he heard or possibly passing on advice he's heard from others that at least on its face sounds reasonable.

If you really want to claim absolutely no authority, then fine.  But then you'll really come up with a better mental excuse to removing/commenting to comments than "but that's wrong and people might take it to be authoritative in some way".  Otherwise, you really should include those little social niceties of clarifying your involvement in advice.

Well, all of the above advice/rant/whatever-you-wish-to-call-it assumes that you wish your blog to be sensical in some way and not just a collection of obtuse arbitrariness.

@Evan

>> But most cars aren't the only ones on the road, which means that other drivers aren't insulated.

What does really help here is ACLs on network drives; I didn't say the current security measures should be removed and replaced, I said that they are like, 5% of what we really need. For what it matters botnets, etc. you can do quite some damager with standard users accounts; sure you will not (depending on the OS) be able to use the network card in promiscuous mode or send RAW IP packets or forge IP packets with invalid addresses.. but nothing stops you from sending an email, or opening connections.

>> The problem here is that I'm not convinced there is a good way to do this. How does the OS know that the download manager shouldn't be able to open your address book, but your mailer should? They are both just processes to it, ruing a specific image.

Probably the whole concept should be revisited for true. For example, apart for private files of the app (with which it can do what it wants), all files should be inaccessible by default, with inaccessible meaning also not enumerable. Access would be granted only after  an open dialog, drag&drop or doubleclick in folder. All of these should be implemented and insulated so that emulation would not be possible (for example not being able to enumerate files and opening them using tokens instead of filenames). Removing should be allowed only by the shell (which should not be a standard process anymore.. stop an useless generalization). Messaging between apps removed, allowing only sockets or shared memory for IPC (that is, removing the hole where every process can send commands to the others using SendMessage or similars). We can go on. For sure it's not something you can plug in an existing architecture and pretend to work.

'[The conclusion from the previous round of arguing about this was that I didn't have to reiterate "This information is not authoritative" in every blog article.'

Which leaves me to wonder the point of your blog, if nothing you say is authoriative.  Perhaps I'd feel differently if all of your blogs was based on readily available (ie, avaialble to the general populace) information and didn't include follow-ups based on communications between Microsoft employees.

'I have no current intention of revisiting the issue any time soon.'

Fine.  

'(And I did clarify my involvement: I said that it was a recommendation of other people, not me personally.) -Raymond]'

See, that doesn't entirely clarify your involvement.  Are you quoting a good friend or an authority that you trust?  Are you qouting a random stranger on the street?  Did you put very little thought into the validity of the statement?  Did you put heavy thought into the validity of the statement, possibly as far as a proof?  The only thing that is clear is that the information didn't directly come from you.  I do hope that you do some filtering of information provided to you that you pass on to others.  But, given how you don't want to claim any authority behind your words, I can only really hold it to the same level of a fiction writer trying to "fill in the space" that's left from coming up with other crazy ideas of which they wish to claim no responsibility.

Evan, are you familiar with .netfx's security permissions? I am not entirely fluent in that area but I think it does implement process level security nicely. You decorate your code with the permissions you need and during startup CLR verifies that requested permisssions can be made available, otherwise, the process doesn't even start in the first place. You also have the option to make the CLR specifically revoke certain permissions you know you will never need.

Raymond said : "If a frequently used buffer is paged out, then your program is thrashing and protecting 10 pages from being paged out is going to make the thrashing worse (since those pages become unavailable for relieving the thrashing)."

If my program locks a buffer size of a L1 cache and uses it to stream say 2GB of data through it, then if the OS decides to page something out while caching input and output files, I would rather that it pages out _anything_else_but_that_buffer_. I just can't trust the OS to do that, that is why I lock the buffer.

You are saying that my program is trashing, why are you making such an assumption?

What if Indexer has decided that it is time to update its database? What if antivirus has decided that it should run its monthly full system scan? Or the defragmenter? What if some other program starts leaking memory and using 100% CPU? Should I not try to prevent them from degrading my code's performance?

Kuwanger, stop boring Raymond to death please. He has the right to write as he sees fit on his own blog. If you don't like it go away, it is his blog, not yours. He is setting the rules, not you. Even if they are wrong you can do nothing about it except bitch and moan which annoys the hell out of everyone here.

Tanveer said : "Igor, are you referring to this CreateRemoteThread..."

Yes I am. If you already have SeDebugPrivilege, you could use NtSystemDebugControl() to gain full control over the system. Why bother reading the process memory when you can execute in its context and do whatever you want from the inside?

An example of dumping the physical memory using NtSystemDebugControl():

http://www.ntsecurity.nu/onmymind/2007/2007-02-04.html

@Tanveer Badar

"Evan, are you familiar with .netfx's security permissions? I am not entirely fluent in that area but I think it does implement process level security nicely. You decorate your code with the permissions you need and during startup CLR verifies that requested permisssions can be made available, otherwise, the process doesn't even start in the first place. You also have the option to make the CLR specifically revoke certain permissions you know you will never need."

You're missing the point... the problem isn't how to implement the mechanism, it's how to specify the policy.

How does the OS determine if the permissions can be made available to a specific application? In other words, if X.exe specifies that it needs write permission to same file, how does the OS determine if it should grant it?

In other words, say thunderbird.exe and virus.exe both specify the same permissions in their .netfx section. The OS needs to determine to give thunderbird.exe permission to, say, read the address book, and deny virus.exe.

'[To answer your questions I would have had to do more research, which I didn't want to do. That's why this is a blog not a textbook. Perhaps you'd be happier if I didn't accept corrections from other Microsoft employees? -Raymond]'

No, you're missing my general point.  This whole blog entry is based upon you believing you knew better than the documentation.  And so people who *would* do research are left to either take your word for it or try to disassemble/gain access to the source code underlying the technology you discuss to verify whether you're right or not.  The fact that someone else at Microsoft is there to correct you that, yes, the documentation is correct underscores how you bow to the authority of *others* in Microsoft.

As for your quoting of others, my general understanding is that you created this blog as a means to inform others (if nothing else, to tell old stories).  But, spreading rumors doesn't really work to inform people unless you make it clear that what you're saying is a rumor.  Of course, the fact that you didn't go out of your way to clarify or harp upon the information you provided does give me, and others, the point that what you mention is probably a rumor.  It just seemed a bit strange that you'd go quoting a rumor that, with a little bit of thought, could be proven as silly.  Isn't one of your largest complaints the way in which rumors are spread by ill-informed people as if they were the documentation, not so much because you're against rumors, necessarily, but because it creates further burdens that have to be corrected and resolved upon?

But, then, I guess one really shouldn't be going to your blog for any sort of programming advice.  It is a great way to hear interesting stories, though.

@Igor: "Kuwanger, stop boring Raymond to death please. He has the right to write as he sees fit on his own blog. If you don't like it go away, it is his blog, not yours. He is setting the rules, not you. Even if they are wrong you can do nothing about it except bitch and moan which annoys the hell out of everyone here."

If Raymond tells me he doesn't want to see me commenting more on here, then I won't.  I don't really say I comment very often anyways (though the few times I have, I tend to respond when people respond back).  I am sorry if the "bitch[ing] and moan[ing] is annoying the hell out of [you]".  I could probably come up with some way to disparage other commenters, but I won't.  It's really up to Raymond to decide if he wants someone posting to his blog or not.  And I really do hope that people, like you, can deal with the few times a commenter, like me, seem a bit grating to them without feeling a need to force them out of commenting.

Short of someone spamming/trolling/committing-some-crime-on the comment board, I don't really see the reason to wish someone to leave.  But, again, I happily defer to Raymond's wishes on such a matter.  But, I won't defer to yours, Igor.

Kuwanger, I do believe Igor is referring to the fact that even though you don't often comment here, when you do, it is generally a long, entirely boring, pointless argument with Raymond over minute technicalities and egos, and your apparent insistence on having the last word. You also appear to be incapable of admitting when you are wrong, agreeing to disagree, and realising when to just drop your argument because nobody cares what you're saying anyways.

Almost every comment of yours (the ones that I've read anyways, I mostly skip over whenever I see your name for this precise reason) seems to involve arguing with Raymond because either

a) he is Raymond Chen, and you feel you will score some sort of nerd points if you are able to win an argument with him; or

b) he works for Micro$$$$$$$oft and so by sticking it to Raymond you are actually sticking it to THE MAN, billy goats himself; or

c) you are actually Norman Diamond in disguise, and this is your sockpuppet account, kinda like twitter and Erris on slashdot.

Regardless, you actually don't contribute much value to the conversation. Please stop the trolling.

"In other words, say thunderbird.exe and virus.exe both specify the same permissions in their .netfx section. The OS needs to determine to give thunderbird.exe permission to, say, read the address book, and deny virus.exe."

In thunderbird.exe's documentation, you could say that it requires the ability to read the users mail, or whatnot to work. Then the user can make an informed choice about what security privileges it needs. The way I see it, if the user is installing a different Email client than the one included in Windows (Which should already have the correct permissions), then they should be informed enough to know it requires the ability to read their mail.

Of course, it's easy to underestimate how stupid people could be.

Actually, one of the added features in Vista (thanks to the demands of the movie industry for better copy protection) is "protected processes", whose memory can't be read by other programs (amongst other things).

Of course, I think they have to be signed by a special key (for obvious reasons, especially since they're immune to virus scanners). Unless you're working on behalf of the media industry, you can probably forget about being able to use one yourself.

"In thunderbird.exe's documentation, you could say that it requires the ability to read the users mail, or whatnot to work. Then the user can make an informed choice about what security privileges it needs. The way I see it, if the user is installing a different Email client than the one included in Windows (Which should already have the correct permissions), then they should be informed enough to know it requires the ability to read their mail.

Of course, it's easy to underestimate how stupid people could be."

But that's not the point. This is supposed to protect against malware anyway, which almost by definition usually doesn't disclose what it does.

The security threats that "the application says it shouldn't have this right, so we'll deny it" solve are a small minority of security threats.

"But that's not the point. This is supposed to protect against malware anyway, which almost by definition usually doesn't disclose what it does."

Yes, but combined with http://blogs.msdn.com/oldnewthing/archive/2007/11/06/5924058.aspx#6031507 and only letting untrusted programs access their own sandbox, it could be a viable security policy that *does* protect from malware.

Raymond said : "If working set memory is being paged out, then there must not be enough memory to hold the working set. Therefore, you're thrashing."

I always take care not to use too much physical memory. Problem is that I can't monitor what the user (or other resident applications or the OS itself) is doing.

Are you claiming that another program cannot cause my program's working set to be paged out?

Kuwanger said : "But, I won't defer to yours, Igor."

You know what? Compared to you even Norman Diamond deserves respect.

True, he nags, but at least he doesn't force anyone to share his point of view or to do things his way like you are trying to do with Raymond.

"Are you claiming that another program cannot cause my program's working set to be paged out?"

Are you claiming that the other program is less important than yours?

Besides, that's not the point anyway. If there is so much memory contention going on that your working set is being paged out, then VirtualLock isn't going to help you anyway...

"Are you claiming that the other program is less important than yours?"

The programs listed in the example are supposed to be background tasks that do not bother the user.  In the eyes of the user, they are less important than the program he is actively using.

I&#39;ve just uploaded a new open-source project called &quot; Non-Paged CLR Host &quot; to CodePlex