Patching, patching, patching
-
I read last week that Oracle released 51 security patches for various products. That's a lot of patches, but it somewhat pales when compared to the 101 they released last October. Since Oracle does quarterly releases, I was wondering if that's a lot. Hard to tell and honestly since I'm a database guy I wanted to check on database issues only.
When I got to the Secunia web site, they show that there are (14 for 10g, 24 for 9.x, and 17 for 8.x). Of these, thre are 3 unpatched for 10g, 1 for 9.x, and 0 for 8.x. I didn't count the various 9.x editions separately because likely there are all the same issue.
For SQL Server, there are these stats:
Version Issues Unpatched SQL Server 2005 0 0 SQL Server 2000 10 1 SQL Server 7 8 2 I'm not quite sure how to compare these numbers, especially when the article lists 26 database security patches for Oracle but Secunia only has a few listed. I'm not even sure there's a good comparison, though I'd be worried about the 10 Oracle vulnerabilities that do not even require a name or password.
All I know is zero is a nice number to have when you're dealing with security vulnerabilities.
-
It still amazes me that they are not hammered in the media about this. Remember years ago when they marketed Oracle db as 'unbreakable' ???? No one mentions that there has not been a single security vunerability found in SQL Server since the summer of 2003, and that there have been over 100 vunerabilities patched in the Oracle db code. What is scary is that data that is supposed to be secured at banks and the like are running mostly on Oracle db's.
I know Oracle DBA's that believe Oracle is the only RDBMS and that all of the others are toy's. Yea, this is great code !
-
Where is the place where the SQL Server stats come from? Does it list the BINARY_CHECKSUM bug?
-
>>All I know is zero is a nice number to have when you're dealing with security vulnerabilities.
That almost sounds like an advertisement...
Mind you, as long as the stats (for both) are acccurate - I would be thinking that Microsoft should be shouting that from that the rooftops. Trying not just to get people to upgrade to 2005 - but steala few customers away from the other vendors. Perhaps they don't want it to be seen as a challenge?
If it were me, though, in a world where everyone loves to knock Microsoft - even the guys who only know MS products - I would certainly be aggressively marketing the virtues of mine is better / safer than yours... well at least until the next get flaw is found anyway!
Gavin Baumanis
Smith and Wesson. The original point and click device.
-
Gavin,
I bet that there's worry or maybe they're working on patching something that hasn't been announced. All software has bugs, but it is curious it hasn't been mentioned more.
David Litchfield did an analysis recently and pointed out that SS2K5 hasn't had any vulnerabilities, and I'm surprised I haven't seen that more. Course, maybe the sales guys are pushing it quietly so Oracle will continue patching at their snail's pace.
Note that this isn't "bugs". If it were, we'd have too many to count or would be noting them with the ^ notation. This is security issues. The binary_checksum is a bug, but I'm not sure it's a security issue. It can be used for a denial of service, but not compromising the security.
-
One thing that was mentioned earlier in the thread is that it's a concern that there are all these security flaws in a Oracle which is the primary platform used by banks.
I wonder if atleast some part of the reason there are so many reported vulnerabilities is that we're talking about a platform used by banks. How many of the bugs are found simply based upon the level of paranoia surrounding big finances.
A lot of shops are more concerned about an external attack then an internal attack. So they're going to consider a vulnerability that requires access to their network to be a vulnerability in the network before they consider it a vulnerability in SQL Server. They're concern is that the front door is hanging wide open, and if it was closed properly, no one would have access to their portable safe that's not locked... I mean after all... Their data just isn't quite that... sensetive...
Banks on the other hand have a huge concern that they encounter an internal attack... these are people handeling a lot of money, and they don't even want their IT staff to have access to the data. They're paranoid to an extreme, and all too familiar with social engineering attacks to leave their safe unlocked. So, they abuse their software with every battery of tests they can come up with. The need to... if their database gets compromised, we're talking a lot of dollars...
Honestly... if our database was compromised, I think about the worst impact would involve contact information, or sales figures. there's just no way that I can think of for someone to skim $1 off of each of 10,000,000 accounts, or quietly collect $.01 off of every interest transaction and dissapear to the south pacific.
Oracle, which runs a lot of financial infrastructure has reported security vulnerabilities.
DB2, which runs the back-end of a lot of very big companies has reported security vulnerabilities.
SQL server which is best known for running the back end of web sites, running business logic, and is by comparison just recently beginning to branch out into more security sensitve roles (accounting, payroll, etc) however doesn't have many...
what is SQL server's market share in the finance industry, or in fortune 100 companies financials?
-
Well I actually think this issue, for SQL Server, pales into total insignificance compared to the basically lousy security within the third party apps that run on SQL Server. ( I have worked many years in financial insititutions + SOX etc. ) Now I don't know if apps run the same on Oracle or DB2 as I don't have that exposure currently.
e.g. In the main the best security I have found in any thrid party app is to grant all users datareader/datawriter + execute all procs ( if there are any ) You explain to me where the security is here. Many seriously expensive apps only use embedded/dynamic sql so table rights have to be assigned, so no security here then?
And need I mention all the apps which require to run as dbo and require all users to be dbo, and yes there are still the sa users.
Passwords and sysadmin accounts on these apps - universally well known and never change, and quite often you can't change them anyway. most apps use the app name as the password so if your app is called PingPong ( apologies to any app of this name ) sysadmin account likely to be called PSA and password PingPong - you might want to try this on your fav app --
Intergrated secrity is rarely any better with usually all users dropped into one group and given datareader/datawriter.
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply