Is this woman aware that static analysis is a non-negotiable requirement for filing your 510(k) if you do anything vaguely medical the FDA has to look at? Not that I would willingly choose Oracle for medical device applications, but the cognitive dissonance here is amusing. Pax vobsicum indeed.
“Stop reverse engineering our code”
161–170 of 358 posts
Re: “Stop reverse engineering our code”
#162Earlier quoted context omitted.
Reverse engineering software is completely different from penetration testing, and it is the reverse engineering bit that Oracle has an issue with. They mostly just don't want anyone/everyone trying to recreate their source code because of copyright/intellectual property concerns (note: I do not agree with those, but that is Oracle's stance). It doesn't make sense for it to be illegal to forbid reverse engineering in…
> Reverse engineering software is completely different from penetration testing How is it so? You cannot find funny vulnerabilities without reverse engineering the binaries. > It doesn't make sense for it to be illegal to forbid reverse engineering in a license agreement, where is that the case? France, Switzerland, Russia and many more. > it would make more sense to just forbid closed source software How did you mak…
I think there may be a language barrier here. So, this should clear it up:
The only definition of "reverse engineering software" that I use is this -- "Using tools and deep binary analysis to take a compiled binary, and convert it back to source code as close to the original as possible".
It is a very specific definition. I do not mean general "analysis" or vulnerability testing or input manipulation, etc... only attempting to discover source code.
Re: “Stop reverse engineering our code”
#163Earlier quoted context omitted.
who knows – in many ways it's even better if it's satire, because it's just believable enough.
If it didn't have a 'most likely' in it I'd think it was satire, but that's the kind of weasel wording that you'd expect in a real release. There was another post in much the same vein on that blog: https://blogs.oracle.com/maryanndavidson/entry/those_who_can...
Who's she attacking in that post (SASO)? Veracode?
Re: “Stop reverse engineering our code”
#164Re: “Stop reverse engineering our code”
#165Wow. Really? This single blog post is strong evidence for why you should never, ever buy an Oracle product, and if you are running anything written by them, why you should plan to migrate away. Now, the culture of consultants in the Oracle sphere of influence is pretty toxic and money-grubbing. I can imagine companies being badgered into paying security weasels big bucks to analyze software with tools that cough up a…
Stanford was taken to the cleaners to the tune of $1.5 x 10^8 USD in the deployment of Oracle Financials and related products via endless "consultant implementation" charges that didn't really deliver much value, were rarely on schedule or on budget. Oracle's enterprise calendaring program was totally inadequate and had UX that made most point-of-sale systems look effortless by contrast. Also, the assets managing app…
> The client must hire their own project managers, have clear accountability/authority paths to their management and know exactly what they need (avoid endless upselling).
This so much. Especially the "know exactly what they need" side of things. I speak from the consultant side of the fence, and we've had a number of projects where project management was lacking on the client side; it ends poorly.
We always have our own project manager on projects, and we strongly encourage the client to have their own as well. It really helps to maintain a clear escalation path, and makes everything run much more smoothly.
Re: “Stop reverse engineering our code”
#166Earlier quoted context omitted.
She has a point here. Static analysis does generate a lot of false positives, and it requires a pretty in-depth understanding of the code to determine whether any given hit is a real issue. Unfortunately, that sort of understanding doesn't usually come from just running a static analysis tool (or fuzzer, OWASP scanner, etc., etc.). The problem comes (and I have personally been on the receiving end of this) when runni…
Oracle cannot ignore annoying and low-expected-value static analysis tickets, but: 1) the answer should usually be either "fixed in this patch, install it" or "it's a false positive, try developing an actual exploit if you don't believe us". Not expensive, provided Oracle actually runs static analysis tools against their software and addresses the findings before releasing updates. 2) If Oracle actually runs static a…
Ah...you've never used one of these tools on a large code base. The problem is that when I run the tool in my QA environment, I identify the false positive and configure my tool to account for the false positive (or I create a compensating control). If you run the same tool, you'll see everything I tuned out, and I then have to go back and trace where the finding was tuned out, why it was tuned out and make sure that's still right. It's not inexpensive when multiplied by hundreds of times. And that's if you use the same tool as I am; if you're running different one, we just as well could be starting from scratch.
Finding something, and worse finding something over and over again, means that Oracle QA is inadequate.
By what delusion do you think it's not the tool finding the same false positive over and over that's inadequate. The tools are not perfect, and often their developers are very obstinate in what they consider a finding.
Re: “Stop reverse engineering our code”
#167Wow. Really? This single blog post is strong evidence for why you should never, ever buy an Oracle product, and if you are running anything written by them, why you should plan to migrate away. Now, the culture of consultants in the Oracle sphere of influence is pretty toxic and money-grubbing. I can imagine companies being badgered into paying security weasels big bucks to analyze software with tools that cough up a…
Turns out to be Oracle's chief security officer.
Read the other blog posts. Holy cow crackers.
Re: “Stop reverse engineering our code”
#168Earlier quoted context omitted.
Yeah, it's very poorly written. I always cringe when some exec thinks "oh, it's just a blog so I don't have to write with the same professionalism and attention to detail that I would in other corporate communications".
Well, it's not even 'just a blog', it's a blog hosted by oracle.com about the author's employment at same. The standard of professionalism should be higher given the direct link, methinks. If it were a personal blog on a personal topic, it wouldn't matter as much.
I think if recent history is any guide, a C-level who claims "you can't hold me accountable for stupid shit I say on my personal blog" isn't going to be one much longer.
Re: “Stop reverse engineering our code”
#169Wow. Really? This single blog post is strong evidence for why you should never, ever buy an Oracle product, and if you are running anything written by them, why you should plan to migrate away. Now, the culture of consultants in the Oracle sphere of influence is pretty toxic and money-grubbing. I can imagine companies being badgered into paying security weasels big bucks to analyze software with tools that cough up a…
I went to a prominent tech school that adopted an Oracle platform for student course management in my last few years. I won't mince words: it was a piece of shit, and my school's administrators ate shit by agreeing to a contract that forbid them from making any changes to Oracle's broken system. Now I work in college administration and we have to deal with the very same pile of junk. Someone once told me that Larry E…
You might want to fact check yourself on Rockefeller:
Founded 1870, antitrust 1911:
https://en.wikipedia.org/wiki/Standard_Oil
Crude prices in that time frame (and beyond):
https://commons.wikimedia.org/wiki/File:Oil_Prices_Since_186...
Production in that time frame (having trouble finding a nice long time-series chart):
https://en.wikipedia.org/wiki/History_of_the_petroleum_indus...
If we want to make a strong claim of harmful monopoly[0], we should not expect to see a massive surge in production combined with an impressive decrease in price.
[0]Here I use the term "harmful monopoly" to refer to a firm that has both market power (can influence prices by controlling supply) and uses it to increase its own profits. What we see instead is a time period where we do indeed have a dominant firm, but one behaving as if it were in a competitive market.
The important characteristics of a competitive market here are low barriers to entry/exit, and a commodity product. There were incredibly low barriers to entry/exit, and oil has, for nearly its entire existence as a product in the modern age, been a commodity.
Re: “Stop reverse engineering our code”
#170Earlier quoted context omitted.
> Reverse engineering software is completely different from penetration testing How is it so? You cannot find funny vulnerabilities without reverse engineering the binaries. > It doesn't make sense for it to be illegal to forbid reverse engineering in a license agreement, where is that the case? France, Switzerland, Russia and many more. > it would make more sense to just forbid closed source software How did you mak…
I think there may be a language barrier here. So, this should clear it up: The only definition of "reverse engineering software" that I use is this -- "Using tools and deep binary analysis to take a compiled binary, and convert it back to source code as close to the original as possible". It is a very specific definition. I do not mean general "analysis" or vulnerability testing or input manipulation, etc... only att…
> The only definition of "reverse engineering software" that I use
Uhm, no, that's far too narrow. Reverse engineering is any kind of introspection into a device in question, designed for obtaining any degree of understanding of its inner functioning.
What you're talking about is called "decompilation", and it's not even among the most useful reverse engineering techniques.