Another big flaw has been discovered in Microsoft software just a few days after they broke their patch cycle to issue a patch for the IE bug that allowed remote code execution.

This time however it doesn’t really effect home users or the general consumer, it’s a more specific server side vulnerability affecting Microsoft SQL Server 2000 and 2005 versions. It seems pretty serious though as it also appears that this vulnerability if exploited properly could lead to remote code execution.

Just days after patching a critical flaw in its Internet Explorer browser, Microsoft is now warning users of a serious bug in its SQL Server database software. Microsoft issued a security advisory late Monday, saying that the bug could be exploited to run unauthorized software on systems running versions of Microsoft SQL Server 2000 and SQL Server 2005.

Attack code that exploits the bug has been published, but Microsoft said that it has not yet seen this code used in online attacks. Database servers could be attacked using this flaw if the criminals somehow found a way to log onto the system, and Web applications that suffered from relatively common SQL injection bugs could be used as stepping stones to attack the back-end database, Microsoft said.

Desktop users running the Microsoft SQL Server 2000 Desktop Engine or SQL Server 2005 Express could be at risk in some circumstances, Microsoft said.

Again I wonder how far behind the curve Microsoft is with this? Usually these kind of bugs have been discovered by the more malicious parties way before Microsoft has any idea that their software is vulnerable.

It claims that the code hasn’t been used in online attacks, but honestly if it was used well by a smart party who would even know? SQL injection could lead to this attack being executed and the code is published online so I find it unlikely that it hasn’t been used.

The bug lies in a stored procedure called “sp_replwritetovarbin,” which is used by Microsoft’s software when it replicates database transactions. It was publicly disclosed on December 9 by SEC Consult Vulnerability Lab, which said it had notified Microsoft of the issue in April.

“Systems with Microsoft SQL Server 7.0 Service Pack 4, Microsoft SQL Server 2005 Service Pack 3, and Microsoft SQL Server 2008 are not affected by this issue,” Microsoft said in its advisory.

This is the third serious bug in Microsoft’s software to be disclosed in the past month, but it is unlikely to be used in widespread attacks, according to Marc Maiffret, director of professional services, with The DigiTrust Group, a security consulting firm. “It is rather low risk given other vulnerabilities that exist,” he said via instant message. “There are a lot of better ways to currently compromise windows systems.”

The bug was discovered by someone in April this year, so that’s at least 7 months someone has known about it..but only know when the vendor discloses it then Microsoft chooses to say something about it.

It is a fairly low risk vulnerability due to the requirements needed to execute it effectively, but still it’s another chink in the Microsoft armour to add to the (long long) list.

Source: Network World

Microsoft has taken a bit of a leap with the integration of .net into SQL Server, and a lot of developers(Myself included) are worrying about what security implications this could have. DevX.com have taken an in-depth look into the guts of it, and spilled them onto a page for us all to look at.

CAS provides a code-based rather than user-based authorization scheme to prevent various kinds of luring and other code attacks. But how does that security scheme coexist with SQL Server 2005′s own, newly enhanced security features? By default your .NET code is reasonably secure, but it’s all too easy for the two security schemes to butt heads and cause you grief. In this article I’ll look briefly at the concept behind CAS and a few new security features in SQL Server 2005, then explore how to make the two systems work for you instead of against you as you take advantage of these advanced programming features in SQL Server.

They seem suitably impressed, but sensibly wary at the same time.

The good news is that Microsoft did a great job bringing together the security systems of SQL Server and the Common Language Runtime, with tools to control code. But there are some interesting features’ both to watch for and to take advantage of!

At the place I pretend to work, the time has come that most developers equally fear and love, upgrade time. We’ve been using MSSQL2000 for 90% of our work for about 4 years now, and it’s served us well, but when a change as big as 2005 server comes along, you have to make the leap and upgrade. I suppose a little background is in order, but I’ll have to keep it fairly general as we have some strict rules on what we talk about with people outside the development team.

What we do now

The company I work for is a travel company, one of the big ones, and as with most big travel companies we do a huge variety of things. We own resorts, broker our own insurance, sell for third parties, sell our own holidays, own/rent cruise ships, provide resort management for small hotels, and many other things, all of which is managed through 3 internal sites. We handle the telephone auto-diallers in the call centre, stock-management at our red-sea resort, the links to the main UK flight database, the payment system, our SMS marketing servers, basically, everything.
We have 3 main centres, our corporate headquarters in America, the headquarters in the UK and 1 huge sales centre in the UK also. In addition to that we have either fixed line or internet linked terminals at all our resorts, most of the major airports, all of which connects to our headquarters in the UK(It’s an ex-cupboard upstairs). Because of the international nature of our business, and the resort links the sites must run with 100% uptime 24/7, even though they are all internal.

The sites run on a variety of different platforms, but the vast majority run on old style ASP and SQL server 2000, with a heavy focus on SQL server. To put the workload in perspective, our ASP apps use approximately 5% of our server’s total resources, with SQL server taking the other 95% and another magical 1% running Reporting Services (An excellent application if you’ve never used it). We have a multitude of databases, but we currently run on 4 SQL servers with the databases split as equally as we can get them to avoid having to deal with load balancing. The databases range greatly in size, from a few MB for the HR database, too over 50GB for the lead details database (Call centre data).

Why were upgrading

Due to the size and complexity of the database, performance is extremely important and we have our indexes and maintenance jobs tuned to absolute perfection or the entire thing would come crashing down around us, and we would have a lot of angry people looking to have our heads. But recently we have hit SQL server 2000′s “roof”, which is one of the reasons MSSQL has never challenged Oracle in the big enterprise market, and its proving a big problem for us. SQL server 7 was never meant to be an enterprise level database server, and in typical MS style a lot of SQL server 2000 has come from that original code, as have a lot of the problems, mainly its inability to handle truly massive database. 2005 fixes this.

SQL server 2000 was also limited in that it handled everything via transactions and locking, so if you want to retrieve data from the database in an editable format you have to basically lock that information so nobody else can access it. This can cause all kinds of problems, such as one user being told they can’t perform an action, because their locking themselves (Usually through bad coding) or a deadlock which is data being altered while they are waiting for a lock to end. 2005 borrows from Oracle in that is uses a combination of locking and versioning, which takes a copy of the data, performs the action on it and then puts it back into the database. This presents its own problems, but it does mean users can always get to their data.

There are also some significant coding changes, including some very cool stuff that is new to database servers as a whole. The ability to include code from other languages is one of the main talking points, which basically allows you to execute .net code within your stored procs. This may not sound so great, but you have to consider how it changes the way a DBA will work. At the moment database code needs to be specific, because speed is always an issue the server has to constantly optimize the way it works, and it can’t do this with vague and dynamic code. For example…

Select * from Invoice

Would bring back everything from the invoice table. But what if we just wanted a price field?

Select Invoice.Price From Invoice

That’s easy enough. But what if we wanted the gross price, for example, from insurance items, but the net price for everything else. We would do this(Pseudo-code);

Select (if Invoice.catagory = ‘INSURANCE’ then Invoice.Gross else Invoice.net end if) from Invoice

Again, it looks simple enough, but unfortunately the real code to do this is very complicated and grossly in-efficient at the moment, not to mention completely impossible in certain situations. In 2005 the method above would be perfectly legal, and using Microsoft’s CLR compiler to pre-compile the code, it’s considered adequate (It’s still not as good as plain SQL, but its good enough). This and the performance improvements in the new server would be enough to warrant an upgrade on their own.

What were doing next

We have setup 2 MSDN’d 2005 servers and mirrored our web server as a test bed for upgrading our code. Fortunately the vast majority of our code will still work, but to take advantage of the upgrades and new features we will have to re-write vast swathes of code. And all of our 500+ DTS’s and jobs will have to be completely re-written. And then comes the fun of learning an entirely new interpreter and compiler, and tuning it for maximum performance.

I’ll keep you updated