Oracle Database 12c's data redaction security smashed live on stage Oracle’s much-ballyhooed data redaction feature in Database 12c is easy to subvert without needing to use exploit code, attendees at Defcon 22 in Las Vegas have heard. The redaction features in 12c are designed to automatically protect sensitive database material by either totally obscuring column data or partially masking it …
"The result down the line was that patching and flaw detection in Microsoft SQL dropped sharply, and the code security of IIS and Exchange has also been much improved. Oracle should take a leaf out of Redmond’s book when it comes to security, he suggested, and customers should demand change."
It was a bit more extreme of an impact than that. SQL Server vulnerabilities in the last decade have been single figures, whereas Oracle's DBs have had hundreds...
"Ever tried reading any of their install scripts?"
Never mind reading them - even trying to use them can be an utter pain if the system doesn't have EXACTLY what the script is expecting in EXACTLY the right place. I'm pretty sure they give the install script writing job to the interns because I simply don't believe they've been written by professionals since they are so utterly appalling.
I especially like it when something silently fails, but you can't really tell what it is because they only updated the installer and not the packages.
Or how every oracle product will come with it's own JVM but whether it's using the one it's bundled with or the one in your environment variables is pot luck a lot of the time.
"it's clearly more than just fishy, it's obvious that Microsoft is paying them to do this public attack."
Take a look at say SQL Server vulnerabilites versus Oracle DB ones and then say Java vulnerabilites versus .Net ones over the last few years. Microsoft have had roughly 2 orders of magnitude fewer holes in their code! You might not want to consider Microsoft secure, but Oracle are far far worse.
@Joerg
>These researchers attacking Oracle and praising Microsoft.. it's clearly more than just fishy, it's obvious that Microsoft is paying them to do this public attack.
Exactly, especially when the "guru" then goes on and specifically quotes the sieves ...
"Why did Sun have to get bought by Oracle?"
Because even when the writing was on the wall in 10 foot high flashing neon lights , McNealy and pals still thought people would pay 5 digit prices for their unix workstations and low end servers when x86 + linux/windows had already eaten their lunch and was on to desert. They just about managed to keep making money at the high end but not enough not to need rescuing
Its a shame because Sun desktop workstations were fantastic pieces of kit back in the day and if Sun had charged sensible prices they could have easily competed with Macs & PCs for graphics intensive apps. But pay 10K for the same sort of performance you could get for 3K with x86 or PowerPC Mac? No one is that stupid.
I'm not sure it's an entirely fair criticism. I believe redaction or masking is not meant to 'secure' the data. For that you should be using encryption or other methods.
The functionality is designed to mask certain data from *applications* not from people who can craft SQL. Masking is inherently insecure against carefully written SQL where someone can write queries like select COLA from TABLEA where COLA like 'A%'
With this you know the value starts with A (or not), repeat this process manually or script it until you have the data you want. This is not a flaw in the implementation just a fact of life for masking
It should only be used where the query is fixed (like from an application call) and you want the data to be masked in the application GUI
I feel like you're thinking of something that I'm not understanding completely.
For all the use-cases I can come up with, either the application is trustworthy (in which case masking is unnecessary), or the application is not (in which case masking is insufficient).
If an application is going to display a credit card number in its GUI unless the database is supplying masking (because that query is "fixed"), wouldn't that mean we've got an application which shouldn't be used against that database at all?
What am I missing?
If you read the white paper (http://www.oracle.com/technetwork/database/options/advanced-security/advanced-security-wp-12c-1896139.pdf), redaction is primarily intended for retrospective use on existing applications. It allows data to be transparently redacted with no change to the application. For example if your application is currently showing data in a GUI that it should no longer display (perhaps because of enhanced regulation) then a single database command can mask that data wherever it is returned to the application, avoiding a potentially much more tricky application change.
Well done to someone for finding an inference attack that Oracle makes clear it doesn't protect against in it's documentation. From the above pdf (June 2013):
"Data Redaction does not prevent privileged users from connecting directly to the database and running ad hoc queries that back into pieces of sensitive data ( i.e. it does not stop exhaustive ad hoc queries or other inference attacks)."
As to the other points, it is best pracitice for applications to connect via a username that has very limited privileges - certainly only DML (no DDL) and only on the necessary tables and often all access will be via a view and so the underlying table is invisible to the application.
In the scenario where you have followed best practices and you have chosen to use data redaction to meet regulatory compliance.
What happens if a privilege escalation flaw is discovered that means the techniques to allow access to the sensitive data no longer work?
Put another way - is data redaction a feature or just a poorly applied coat of security paint that peels off a few months later leaving you with no additional protection?
Except it fundamentally fails at this.
You have an old app that shows CC numbers - and use redaction to hide them.
However redacted data is still used in the SQL where clause.
As evil identify thief I get a job in customer services. And my lunch break is spent performing the following search on the application:
Customer ID = 'My Target' AND CC Number like '1%' - 0 results
Customer ID = 'My Target' AND CC Number like '2%' - 1 results
Customer ID = 'My Target' AND CC Number like '21%' - 0 results
Redaction is broken - I don't need to see the CC Number to know what it is.
Indeed. Oracle's own docs (http://www.oracle.com/technetwork/database/options/advanced-security/advanced-security-wp-12c-1896139.pdf) say "Data Redaction does not prevent
privileged users from connecting directly to the database and running ad hoc queries that back into pieces of sensitive data ( ie. it does not stop exhaustive ad hoc queries or other inference attack ). "
"Data Redaction does not prevent
privileged users from connecting directly to the database and running ad hoc queries that back into pieces of sensitive data ( ie. it does not stop exhaustive ad hoc queries or other inference attack ). "
You would need to utilise Oracle Database Vault to stop privileged users seeing sensitive data.
For more information on data redaction:=>Technical Information=> Security Solutions=> Oracle Advanced Security
"Oracle Advanced Security, a commonly used option with Oracle Database Enterprise Edition, provides two important preventive controls to protect sensitive data at the source including database encryption (Transparent Data Encryption (TDE)) and on-the-fly redaction of display data. TDE stops would-be attackers from bypassing the database and reading sensitive information directly from storage .. ref
Uh, that's not what on the fly redaction protects, as has already been mentioned. There are other methods that would be used to secure from the exploit in question.
I guess I need to change my career path, I could easily start combing through the release notes of some of these large tech companies for things their features don't protect against and then create an exploit of that thing that doesn't protect against my particular method of extracting data and become a "security expert" and make money as Chicken Little.
Now, it would be so much harder to describe a possible way for a privileged user to access data they should not using some clever SQL and describe how to design the overall environment to protect the data delivering value to the conference attendees, but exploiting a "flaw" that the manufacturer says they don't actually protect in that manner is much easier. Its basically the meatspace version of keyword spam. ORACLE SECURITY FLAW MICROSOFT SQL THESKYISFALLING
This is a load of PR, which why I think it is actually Microsoft PR stunt. This feature is documented as a weak hack to hide stuff in ui's. It is by far the easiest way to hide this stuff from the drones without too much trouble while the application is being re-written. As for the others executing queries ... you wanna execute queries? you first have to find an SQLinjection entry point before you can issue any ... Nobody lets the drones connect to the production database with a client (e.g. SQLPLUS) ... imagine, somebody could have done the following, before the obfuscation:
spo /tmp/ccdata.txt
select cardnr, expdt, chrnr from customers;
spo off
If you have this type of system (drone can access with other clients), you really need to sue the shit out of the system admin for fraud (this is beyond incompetence).
Note that this usually is an acceptable implementation for sysadmins with MCSE/MCSD cards, afaik/from what I've seen.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
