![Security Security](http://a.fsdn.com/sd/topics/security_64.png)
![Businesses Businesses](http://a.fsdn.com/sd/topics/business_64.png)
![IT IT](http://a.fsdn.com/sd/topics/it_64.png)
Oracle's Chief Security Officer Speaks Out 112
s0u1d13r writes "ZDNet Australia posted a special article from Oracle's CSO regarding the treatment and publishing of exploits and vulnerabilities by security researchers. From the article: 'There's a myth about security researchers that goes like this: Vendors are made up of indifferent slugs who wouldn't fix security vulnerabilities quickly -- if at all -- if it weren't for noble security researchers using the threat of public disclosure to force them to act.' An interesting read from the perspective of one of the largest software vendors accused of ignoring vulnerabilities by software researchers."
Rubbish as usual (Score:5, Interesting)
Don't read the 'article' - don't post stories like this onb
Re:Rubbish as usual (Score:3, Insightful)
Eh? In all seriousness, I've come to expect no better.
Re:Rubbish as usual (Score:1, Insightful)
Ummm, last time I checked, MOST corporate hacking was done from the INSIDE, NOT the Internet. K. Thanks.
Re:Rubbish as usual (Score:2)
Really? Where does one "check" this?
Re:Rubbish as usual (Score:1)
> Really? Where does one "check" this?
No - you don't! Because it is not published anywhere. I lost count on 70's and 80's before I got tired of the whole business - internal fraud is huge but hidden, if you are a smaller player, you are fired and if you high enough you are either promoted or retired but no word ever gets out - bad publishity for company. So - as someoneone already said - old stuf
Re:Rubbish as usual (Score:5, Insightful)
And all that from a company that marketed its product as "Unbreakable" despite dozens of security problems every year.
Scum.
Re:Rubbish as usual (Score:2)
Oracle is pretty large software company, thats like saying that Microsoft Windows are unstable because your Age of Empires have bugs and crash.
Re:Rubbish as usual (Score:1)
And I don't get her example about how they need to analyze risks, and therefore holding the patches.
If they find that this particular version's got a bug, put the patch on the net while analyzing other versions at the same time.
At least those who are really diligent can choose to patch the system.
Heck if they're worried about update costs of the customer, let the patch to be removable. Someone could patch the program now, and then if there's a better one, they can install that instead.
The fact is tha
Re:Rubbish as usual (Score:2, Insightful)
Agreed. Just for good measure, a quote:
| In reality, many of the best researchers aren't the ones you hear a lot about, because discretion is their stock in trade.
Well, if they don't publish, you can hardly call them researchers, can you? I guess the author expects tame consultants that work for "credit" only. So: don't read the article.
Re:Rubbish as usual (Score:2)
What's worse, a hacker bringing down your system, or an untested patch for a potential vulnerability bringing down your system? Security fixes cause just as many problems
Too much organizational process? (Score:2)
It is tough to put out a real product. It is tough to get it into customer's hand and provide the support. It is a lot of work to make sure the fix does not break some
Re:Too much organizational process? (Score:1)
Re:Rubbish as usual (Score:2)
Re:Rubbish as usual (Score:2)
The myth is that researchers are always entitled to credit.
Then she goes on the state 'in so many words' the credit is given not based on it being deserved but based on how they feel about you personally.
In reality, when a researcher puts customers at risk by releasing exploit code for a vulnerability before the vendor has had a chance to fix...
She confuses the researcher with the company that released the flawed product.
The reality is that not all resea
Re:Rubbish as usual (Score:1)
Re:Rubbish as usual (Score:2)
Knowing where high level execs is useful, but her poorly expressed opinions cannot represent what anyone would call a sound example of corporate policy or SOPs regarding patch releases.
It wasn't ballsy, it was just balls.
I'm sure you do a good job posting articles to
Re:Rubbish as usual (Score:1)
Re:Rubbish as usual (Score:2)
But that's true, at least for extensive vulns (Score:5, Interesting)
Let's see, you're a development manager and you have a crazy schedule forced on you from above by some idiotic VP. Now this guy from product support comes along and tells you about this horrible flaw that will require you to shut down all development for two weeks, slip the schedule and have your best people fix it. Then you shut down testing for a month and have your best testers test it. Then there's a pain of pushing out a patch and notifying the customers and bad PR associated with that.
I can easily see how some of the less obvious vulnerabilities would be simply brushed off using "no one is ever going to find out" line of reasoning. Now if you know that someone has already found out and he will make it public in about a month, sure as heck you're going to issue a patch, even if this means slipping the schedule by a month (or in case of Windows by two years). Because if you don't, script kiddies will rape your customer and he will never give you another dollar.
Re:But that's true, at least for extensive vulns (Score:5, Informative)
My reference for the years comment:
http://www.red-database-security.com/advisory/pub
They waited over 600 days for Oracle to patch some vulns. There's no excuse for that.
Re:But that's true, at least for extensive vulns (Score:2)
Re:But that's true, at least for extensive vulns (Score:3, Interesting)
But this is all simplistic. I think the reality is that software developers mostly try to make good software, but there is a pressure to add features rather than allocate resources to creating an internally good product. I have seen it, and I have been guilty of this. In this way having an external force pushing the software development pro
Re:But that's true, at least for extensive vulns (Score:1)
Deparment of Homepage Security (Score:5, Insightful)
Re:Deparment of Homepage Security (Score:2)
The Oracle database is probably one of the most complex pieces of software anyone will ever come in contact with. The source code is extremly complex. The implications of bugs can be enormous (imagine you withdraw $100 from an ATM but due to a bug, you account is showing $1000 witdrawal) or the spac
Re:Deparment of Homepage Security (Score:2)
Re:Deparment of Homepage Security (Score:5, Interesting)
Oracle does _not_ take vulnerabilites seriously. I agree that the oracle database is extremely complex, and the implications of bugs is enormous, but it's not inherently complex. Because of this, claiming that they don't release patches because it's complex is bullshit. Oracle does not need to be as complex as it is.
First, the complexity:
I've been running Oracle just as long as I've been running both Mysql and Postgres (I know what you're saying - oh, he's one of those guys:)), and I know that the features oracle offers can exist without all of the useless bloat oracle tacks on. Mysql can replicate, instantly, to who knows how many databases. Oracle Dataguard is limited to 9. I can restore databases in seconds using postgres, oracle takes all damn day. Mainly because you have to have your ducks in a row with: Arch files, redo files, tnsnames, listener files, spfiles, pfiles, oratab, oracle home, etc. Oracle databases are extemely difficult to get running on a different system. Even exports (exp/imp - what _should be similiar to an sql dump) don't work across OSs. Oracle offers no native sql dump command, instead you have to figure out how to get TORA working. Oracle offers sqlplus, an old, broken command line client that requires unsightly scripting to even start the database.
Oracles documentation is very similiar to their product: Disconnected. Nothing fits. Everything (kind of) works, but noone knows how to put it together, save the people who killed what must be hundreds of thousands of brain cells by doing it by trial and error. Oracle requires java, and lots of it. Oracle requires an oracle database to monitor other oracle databases. It's wise to put this on a seperate installation/box. Doesn't seem to make a lot of sense. Now I have twice as many exploitable boxes, not to mention more to backup, administer, etc. Oracle requires an insane amount of diskspace compared to other databases.
I'm not arguing for mysql/postgres vs. oracle - I'm just trying to say that Oracle does NOT need all of the bloat it currently has. The company could stand to do a complete rewrite of it.
Now, the security:
Here's a perfect example of what I mean:
http://www.red-database-security.com/advisory/pub
The first 6 vulnerabilites are 600(!!!) days old!
Here's a perfect example of their lack of motivation.
http://packetstormsecurity.nl/0507-advisories/Ora
Basically, a vulnerability was disclosed months ago, and oracle fixed 10.x in July's update, but completed ignored 9.x. To quote TFA:
'We contacted Oracle about this issue and Oracle
confirmed it, when we asked why there is no fix
for 9iR2, Oracle said:
"Our development teams neglected to do the backports.
We are working on creating those backports now."'
Leaving production systems unpatched until October! (Assuming oracle doesn't 'neglect' to do it again.
In short, quit reading the marketing bullshit and wake up.
Re:Deparment of Homepage Security (Score:5, Informative)
Using streams replication there is not limit (practically) on the number of servers to replicate to.
Restore and recover takes a long time? Use archivelog mode, unless you have physical corruption that spans multiple disks, there is no need to restore the whole database. restore the corrupt file and roll forward. Unless your last backup of the file was months ago, the operation is done in minutes. Please don't spread stupid remarks that have no foothold in reality. L:earn to use the product rather than display your own ignorance.
Oracle Dataguard has nothing to do with replication. Oracle Data Guard ensures high availability, data protection, and disaster recovery for enterprise data. Data Guard provides a comprehensive set of services that create, maintain, manage, and monitor one or more standby databases to enable production Oracle databases to survive disasters and data corruptions.
Starting a database is simple: sqlplus "/ as sysdba"; startup... How difficult is that?
I don't mind critique of Oracle, but at least get your facts straight!
Re:Deparment of Homepage Security (Score:3, Interesting)
I don't know what gave you the impression that I didn't know my job, or that I was incompetent with oracle, but it's quite clear that you're no stranger to making assumptions.
Restore and recover takes a long time... This depends on what you're talking about. I was talking about worst case...You've got some arch files, some redo files, some dbf files and a new disk you need to
Re:Deparment of Homepage Security (Score:1)
As a fellow Oracle database sufferer, I feel your pain.
Oracle is all about the money - if they can get away without patching (security holes or bugs), then they will. Roll on Open Source where they fix it "because it is the right thing to do" !
Re:Deparment of Homepage Security (Score:1, Flamebait)
Re:they misspelled "truth" (Score:4, Insightful)
But it's not always the case - and that's the point of this discussion. There are two additional scenarios that I have seen:
1. The "security researcher" discovers a vulnerability and either uses it to leverage a job offer or doesn't inform the vendor and attempts to make a name for himself by disclosing it.
This is the researcher's fault.
2. The vulnerability is reported and the vendor implements a fix days, weeks, or months later. Sometimes a patch might require significant testing and QA before releasing it. Corporate bureaucracy might slow everything down.
This is the vendor's fault, but is not always a matter of indifference.
In one of the deciding factors of my decision to start my own company was watching one of our clients delay a project over one year past the original deadline. It was urgent - privacy and security holes galore - but due to indecision, extended vacations, bureacracy, and plenty of other crap the project was never completed during my time there. I left 11 months past deadline. Apparently they launched it six months later.
Indifference? Nope.
Indecision? Inattentiveness? Incompetence? Yes.
Cultural Impedience Mismatch... (Score:2, Interesting)
A software engineer working to maintain the codebase at a company however will say that a whole new layer of protections need to be added to the application to safeguard against this kind of attack, requiring a significant
No, a "myth" is something that ISN'T true (Score:2, Insightful)
And... can you demonstrate otherwise?
Because using your formidable public relations abilities to attack messengers, while totally neglecting to use those same abilities to get word out about what administrators should do when flaws arise in your product doesn't really convince me you're interested i
"security researchers" is a broad rubric (Score:5, Insightful)
The only goal in the article there is to do discourage people from doing the whole "I found a vulnerability, you have 5 days to comply" nonsense. Yeah, sure, it works great if you've got a 1-person operation with no legal team, and no multitiered support system in place to filter out the garbage.
Re:"security researchers" is a broad rubric (Score:5, Insightful)
You miss the entire point. You could be referring to one of two "really big, clunky corporations." Either the "really big, clunky corporation" that needs to upgrade all their vulnerable equipment, or the "reall big, clunky corporation" which actually has to provide the fix. Let's do the last one first:
To sum up: Oracle waited YEARS to fix some of these bugs. I don't care why they were unable to fix them. They got caught with their pants down, after the people who reported them decided that "okay, by now, somebody who'll use these vulnerabilities to actually attack people has probably found them" and subsequently released (limited) details required to inform Oracle's customers of the possibility of vulnerabilities.
Now they're trying to blame those people, who actually gave me the ability to make reasoned decisions? The gall. A year ago I wasn't in a position to choose which software we used in our infrastructure, and now I am. Oracle's failure to act upon vulnerability reports, and their subsequent attempt to disparage those who allowed me to do my job, has lost them any possibility of future sales while I'm in charge (until, of course, they actually change - and confirming that change will require me to actually audit their own practices, which I doubt they'll ever let me do).The saddest part? We're a software development firm which gets to dictate to some really big customers what database engine they use. We're talking about tens of thousands of licenses, easy. Whereas we were previously looking at MySQL, Postgres, and Oracle. Now Oracle is just totally ruled out.
Re:"security researchers" is a broad rubric (Score:2)
Does your company do any type of quality assurance? How the hell can you do proper QA in a few hours, unless it's a trivial fix?
Re:"security researchers" is a broad rubric (Score:2)
That's why I said "hours, days, or - very occasionally - weeks"; not all fixes are trivial :) And yes, we do get trivial fixes in and tested within a matter of hours.
That said, many commercial software companies (such as Oracle and Microsoft) can't even manage to get trivial fixes done - even given months.
There are two types of QA: preventative and exhaustive. We do a but
Re:"security researchers" is a broad rubric (Score:2)
I'm having trouble parsing this sentance. Could you help me out?
Re:"security researchers" is a broad rubric (Score:2)
You do realize that your program is trivial compared to something like Oracle?
Luckily the code is written well enough that there hasn't been more than one or two non-trivial fixes, and the bugs they fixed weren't themselves critical.
It's nice when you can do that.
Re:"security researchers" is a broad rubric (Score:2)
While I can understand the difficulties of beurocracy (I work in a doozy of one), I have little sympathy. Those who would take advantage of these vulerabilities will likewise care little about the politics of big, clunky beurocracies. What they care about is exploiting the systems they find vulnerable. And, even bet
Re:"security researchers" is a broad rubric (Score:2)
Not everything happens slowly in a large corporation. If a company finds out that a flaw in their billing procedures is causing the loss of $3m per day, that flaw will be fix
Cry me a river sweetcheeks (Score:3, Funny)
And IMO, whilest it may be true that NOT ALL vendors are made up of indifferent slugs who wouldn't fix security vulnerabilities quickly if it weren't for security researchers, it's true for most!
Re:Cry me a river sweetcheeks (Score:2)
Damn, man! Did you see how UGGLY that bitch is?
Ewhhhh....NASTY!!
It amazes me.... (Score:1, Flamebait)
That someone with the following qualifications leaps to the position of CHIEF SECURITY OFFICER.
Ms. Davidson has a B.S.M.E. from the University of Virginia and an M.B.A. from the Wharton School of the University of Pennsylvania. She has also served as a commissioned officer in the U.S. Navy Civil Engineer Corps, where she was awarded the Navy Achievement Medal.
Re:It amazes me.... (Score:2)
What do you want? (Score:2)
A cursory google search reveals that she's been working in the secure-systems group at Oracle (albeit in a Product Marketing role) for 12 years. I'd say that's fairly substantial.
http://www.businessweek.com/technology/content/ma y 2003/tc20030529_1659_tc111.htm [businessweek.com]
I'd say YOU lack sufficient "credentials" to post on her lack of sufficient credentials since you obviously didn't look for any sense of her qualifications save for the two-sentence bio provided in the grandparent.
What a lamer.
Re:What do you want? (Score:2)
Dude, did I reply to your post? (Score:2)
Jesus, ease up, Sparky.
Re:What do you want? (Score:2)
I'd say YOU failed to follow the thread properly. The person you indignantly replied to was not responding to your post. I'd guess you have your preferences set to hide posts below a certain score. Go back to his post and click "parent".
Re:It amazes me.... (Score:1)
Re:It amazes me.... (Score:4, Insightful)
Sr. Unix Admin: No degree, was a chef
Unix Admin: BS in Physics, worked in a slaughterhouse before college.
Sr. Systems Architect: No degree, was a chef.
Sr. SAN Admin: No degree, was in the USAF
Sr. SAN Architect: No degree, worked on environmental control units
Someone's education, military record, etc. doesn't prove or disprove that they can do a job. If you believe that, you're falling into the same trap as way too many corporate HR departments.
Not a question of ignoring (Score:4, Insightful)
* Inadequate security planning during the development process.
* Vulnerability reports that get stuck in tier 1 tech support instead of reaching someone who can fix them.
* Venders who allow marketing and other non-technical matters to improperly influence security oriented decisions.
If you've ever done commercial software development then you know exactly what I'm talking about.
The security researchers' solution is to instigate a marketing/public relations pressure on the vendors which compels technically reasonable handling of security matters. Its a counterweight to the other improper pressures, and a healthy one.
And guess what? (Score:2, Insightful)
They don't prioritize security it high enough until something goes wrong. Sure, they may be working on a solution, but it's funny how much more quickly things get done when there's a virus/worm running rampant in your company or a web server was defaced. How many InfoSec departements didn't get the funding they needed until Sarbanes Oxley came around and threatened their CFO and CEO?
The same applies to vulnerability rese
Re:And guess what? (Score:2)
It is a business (Score:1)
Imagine you worked on a problem for a month an then told you can talk about i
Why all the references to Black Hat? (Score:3, Insightful)
Guess what, there was no ultimatum in the latest Cisco fiasco. They simply told him he was lying through his teeth, so he told them to go screw themselves and proved that he wasn't lying. I don't see how a time-based ultimatum was involved. They REFUSED to acknowledge the exploit. THAT is why he went public with it. Nice spin oracle, but totaly ignores the most relevant cause for the fiasco: CISCO refused to acknowledge an exploit, NOT CISCO refused to release a timely patch (they did release a patch, later).
Re:Why all the references to Black Hat? (Score:2)
Lets go over this (Score:4, Insightful)
"1. You should be able to fix this in two days"
No, the document says you need to communicate with the researcher within five days. Microsoft has managed to get responses back to people within twenty four hours -- you can at least talk to people within five times that.
"2. The more notorious I am, the more business I will get"
Frankly, there are absolutely awful security advisories. (That "Monad can be used to write worms" garbage is probably the single most embarassing announcement in the history of our industry, though Secunia's DHS advisory that somehow implied a vuln in LibTiff was remote-critical was pretty bad too). If it's this bad when people talk, imagine how bad it can be from people who don't even try to have a public presence.
That being said -- burning vendors is good for nobody, and I have no particular sympathy for those who ignore the rules and just try to embarass people. But lets be honest -- both parties in the equation can embarass themselves, and the system that's evolved has managed to create the otherwise non-existent cost pressure to solve the problem.
How much money did Oracle make from calling themselves "Unbreakable"? Implies there was a rather significant market desire for what security researchers independently establish.
"3. I should always get credit for vulnerabilities I find"
If you release something you know is bad, and do it anyway because you figure the cost of releasing the product is less than the cost of fixing it -- well, the auto industry has a long and colorful history of doing that, and look at the legislative recall framework that evolved out of that.
Why hasn't similar legislation hit the tech world? Because the community of experts who would normally be calling for it has been otherwise co-opted. Good job, keep it up.
At some point, credit can be for forcing a fault to get fixed, not just for finding the fault. I've been in the large corporate environment -- hell, I've found remote roots in deployed products directly because of Oracle 8's broken TNS listener -- that *someone* in your organization found something is never, ever as compelling a reason to address the fault as someone *outside* the company finding something. Credit is more than just finding the flaw, it's finding it without sufficient internal documentation to know where to look. And the threat -- to be very explicit -- is if someone outside your organization, with no source code, can find the problem, so can a malicious attacker.
Security researchers represent hackers who behave as the malicious might but instead work with a vendor. There are inevitably tweaks necessary to the process -- but the process itself is critical, lest we experience its legislative opposite.
--Dan Kaminsky
If the truth is that your security sucks... (Score:4, Interesting)
And so they should. Its still sort of a free country, and Oracle has no right to control people speaking about their poor engineering.
Theres ways to do this that cause Oracle more inconvenience than others, but Oracle would be the last company to dump its inflated pricing if I said to them it wasn't ethical or caused me inconvenience.
If the problem exists, accept it, and fix it as quickly as possible. Oracle are just upset that when they are informed of vulnerabilities they get exposed to more legal liability than if they can claim they didnt know anything about it.
Re:If the truth is that your security sucks... (Score:1)
Re:If the truth is that your security sucks... (Score:1)
"And so they should. Its still sort of a free country, and Oracle has no right to control people speaking about their poor engineering."
More to the point, there are unlimited opportunities for anonymous public disclosure of this sort of information. The idea that the option exists to suppress it is based on a completely flawed premise.
Shoot the messenger vs Fix the problem (Score:2, Insightful)
maybe just over worked (Score:3, Insightful)
another wild guess (from having seen too much commercial software development) is that too many companies rush to ship working code trying to get first to market, or look good on deadlines etc.
Us vs. Them (Score:4, Informative)
Mary Ann makes some good points. Some (very few in my experiance) security researchers do make threats and unrealistic demands on vendors. Releasing a patch in our case often ment touching over 20 branches of code for various hardware platforms and customer special builds. Obviously, we not only have to research the issue, determine a fix which wouldn't cause other problems, apply the patch, but then QA them including appropriate regression tests.
All this takes months and may cause us to slip schedules (which may negatively impact revenue, but we do it anyways, because it's the right thing to do). Most people when I explained this too understood and as long as I kept them updated (every couple of weeks or so) were more then happy to wait- as long as I could report progress or showed how we were going to work around a problem.
But, Mary Ann is also failing to take responsibility for the failure of many vendors (including Oracle IMHO) to take security problems seriously. Some vendors take years to fix problems (Oracle recently took 700+ days to fix a single vulnerability that an outsider found and was nice enough to keep quiet about, David Lichfield last year canceled his Blackhat talk b/c Oracle didn't fix the problem in time). Obviously, there are those who are willing to bend over backwards to help out Oracle and other vendors, but it's a two way street. Vendors who get a bad reputation in the security community about not working with security researchers are then treated worse by the community.
Most of the security researchers who contact the vendor really try hard to do the right thing and are willing to bend over backwards to help out. Contrary to what Davidson says, it was my policy to ALWAYS give credit to the researcher if they found the issue before we had made a patch available, even if we had found it first. If the person was willing to give us a mailing address, also would also send them a small gift as a thank you for notifying us first rather then going straight to iDefense or full-disclosure. A little common sense and treating others as you would like to be treated goes a long way.
Of course there are those who do try to blackmail vendors. I had one guy in France demand we fly to Paris (from California) on under a week notice, wear certain clothes so he could spot us on a certain street corner with a written job offer for the world's lamest "vulnerability" or he'd go public. Obviously he had watched too many James Bond movies and we told him to fuck off. He ended up going public and we had to deal with it.
Personally, I think Mary Ann Davidsion just made her life more difficult. By painting such a negative picture of the security community she has only perpetuated the image that Oracle doesn't want to work with security researchers and that they're better off selling their bug to iDefense or 3Com. At least then they're guaranteed to get credit for their work.
He's wrong on points (Score:2)
First, he talks about demands for fixes within 15-day or 30-day periods. Sorry, wrong. The behavior that causes so many people to push for full disclosure is vendors not even
As for tying seceurity releases and disclosure to financial quarters, sorry but no. That's not the vendor's call to make, it's mine. If the problem's severe enough I may have to overrule procedure and test and implement the fix regardless. But the vendor can't decide that for me, and I can't decide it for myself if the vendor's not te
Umm, that's SHE (Score:2)
Re:Umm, that's SHE (Score:1)
We wish it was a myth (Score:1)
CSO = not very bright (Score:2)
While Cisco finds the vulnerability "in house" and sits on it for gawd knows how long, the "researchers" are out there finding vulnerabilities with no guidelines from Cisco *ahead of time* that "oh, we know about that one, so it doesn't count".
His wife must love him, he believes in telepathy. Somehow the researchers are supposed to know which defects Cisco has already found in house and not waste their time finding those ones again.
Translation: we don't give a rat's ass how much time these people invest fi
Re:CSO = not very bright (Score:2)
s/cisco/cisco|oracle/g
The red cloud of outrage obscured my vision. Man I'd like to send that guy into space wearing a puffy suit to make some repairs using a sharp pair of kitchen scissors. He might have to pause long enough to use his brain for once rather than reciting monotonously from the gospel of the Needy 500.
Indifferent slugs (Score:2)
Well, maybe some vendors aren't but I know for a fact that some are. A couple of years back we reported a vulnerability to Opera and never heard from them afterwards. I mean, not a single word. It seemed that the whole thing disappeared into a black hole. Indifferent slugs, exactly.
Exploit releasers are all EVIL (Score:1)
Researchers on the other hand do; but these (at least some) are the people that release exploits.
And I see those exploits flood into my inbox, swirl around my system pollute the web I visit.
Releasing exploit code frequently results in some degenerate somewhere making use of the release exploit to do real damage. How releasing an exploit can ever be seen as the action of anyone but an insane crimin
Freedom of the press??? (Score:1)
(True, it may not help with much but at least it may have kept this dolt from having her blatant lies published, perhaps forced someone to check up on her track record of a 2yr turnaround or at least got her fined for
Warranties and Source Code (Score:1)
Excuse me?! The security researcher did not put anybody at risk -- you put your customers at risk, when you wrote that code.
I firmly bel
Re:vendors do ignore researchers! (Score:1)
But on another note, Oracle (among others) really is accused routinely of being slow on vulnerability fixes. What I would like to know is how many people think this is possibly because of one of three factors.
A) Their code is all undocumented spaghetti code
Or
B) They are taking the time to research and do it right
Or
C) They really are just blowing it off because it's not making them money so why put money into it
What do others