The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

SQL Server 2005, .NET and shared memory

In bumbling around and reading today I came across a description of how .NET communicates with SQL Server 2005 Express (and I imagine the full product) and that it uses shared memory.

I've used shared memory in the past and exclusively when I was using it to communicate between two separate processes but ones that trusted each other and used the memory space in a private sense.  Both processes would likely have been written by me.

Does it strike anyone else, that apart from the performance enhancement, that this is inherently risky as a semi-public interface.  I understand it will be managed by some gatekeeping memory manager but even so, it makes buffer exploits look relatively pedestrian.

I shall put my paranoia away now and go back to my python for the day.
Simon Lucy Send private email
Thursday, October 07, 2004
Are they talking about the CLR inside SQL Server feature (eg. running in a different thread of the same process), or a completely separate .NET client running in a different process?

The (nichey non-MS Unix) DB we use today relies entirely on shared memory and we have observed 10x performance gains when we run it in non-shared memory mode. So I have the (perhaps naive) belief that shared memory is important.
NetFreak Send private email
Thursday, October 07, 2004
I can appreciate the performance gains, especially in shifting rows and as far as I'm aware the CLR won't be inside SQL Server.
Simon Lucy Send private email
Thursday, October 07, 2004
In Yukon a CLR will be inside MSSQL, that is a matter of fact. How this relates to your shared memory, though, I am not sure.
Greg Tomkins Send private email
Thursday, October 07, 2004
"that this is inherently risky as a semi-public interface"

It certainly sounds risky, but it really depends on implementation details.

Buffer overflows can, in this case, be more or less trivially avoided - the hostile process can only write (a) to its own memory and (b) to the explicitly shared memory but *not* to other memory inside the server's process - any attempt to do that would cause an access violation in the hostile process, not memory corruption.

There's no significant difference between shared memory and a non-shared area of memory that's filled with arbitrary data from another process prior to validation. In both cases you need to assume all incoming data is risky, and ensure that it won't break something else inside the server when it's being processed.

The only thing that would mildly concern me is the hostile process editing the shared memory while the server is validating or using it. I would hope that even Microsoft developers would be able to anticipate and deal with that.

I'm sure there's plenty of other things to worry about though  ;)

Thursday, October 07, 2004
I'm not convinced it'd be any more risky.

Surely, the shared memory would be treated as a DMZ, in which everything was suspect, if not down-right dangerous.

Of course, there is no such thing as non-trivial software without exploits, but it would be very suprising if MS fell for the oldest trick in the book, again.
Friday, October 08, 2004
IIRC (and I'm too lazy to look it up), SQLServer has had the shared memory net libraries since SQLServer 7 came out about 6 years ago and I've never heard of any significant exploit involving it.

The shared memory is between the client network library and the server network library and has nothing to do with sharing any actual data or SQLServer internals. If the client and the server are on the same machine instead of writing the TDS packets to a socket or named pipe the client writes them to shared memory where the server net library reads them in essentially the same way as they would be read from any stream. I suppose a malicious application that was installed on the server could exploit this to interupt communication with legitimate clients on that machine but that wouldn't really be significantly different than a DOS attack via TCP\IP.

I don't think there is significantly more risk here than any other client access method. It all depends on the quality of the server side code which in SQLServer is usually quite good.
Stephen Martin Send private email
Friday, October 08, 2004

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz