Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×

Oracle Plugs 122 Security Holes 25

Aditi.Tuteja writes "Oracle has released a 'critical patch update' that plugs 122 security vulnerabilities across the company's databases, enterprise applications, developer tools and middleware. Oracle has also started providing additional information indicating whether a flaw can be exploited by remote attackers without any authentication credentials. But, Oracle has failed to deliver its patches on all platforms. Patches for Oracle databases 9.2.0.6 and 10.1.0.5 will not be available until the end of this month. Users running Oracle 10.2.0.1 on Linux on Power servers will also have to wait until the end of October, as will users running Oracle 10.2.0.2 on Windows."
This discussion has been archived. No new comments can be posted.

Oracle Plugs 122 Security Holes

Comments Filter:
  • Good (Score:2, Insightful)

    Odd to see almost all posts before mine are flamebait/troll. Anyway, congrats to Oracle for patching that stuff. You don't see bugfixes like that very often anymore.
    • The thing is... it should probably happen MORE often
    • Re: (Score:2, Insightful)

      by Anonymous Coward
      I can only assume your post was in jest, After all no one could possibly be congratulating Oracle on yet AGAIN issuing another massive set of security fixes. This is a constant thing that happens every 3 months from them and it is getting worse rather than better. On top of there being 122 vulnerabilities they have only published the fixes for a couple of platforms so far so many DBA's have just had there arses exposed by oracle. Yeah great work yet again Oracle
  • by nacturation ( 646836 ) <nacturation AT gmail DOT com> on Thursday October 19, 2006 @10:43PM (#16511979) Journal
    So I guess they're not still flaunting Oracle [cnn.com] as being unbreakable?
     
    • by shamer ( 897211 )
      How long until the flood of "breaking" attempts ?
      • Re:Unbreakable. (Score:5, Informative)

        by SmurfButcher Bob ( 313810 ) on Friday October 20, 2006 @12:23AM (#16512649) Journal
        I'm hoping that Litchfield won't have a good sized list by the weekend... but unless Oracle has seriously changed their definition of "fixing" (and I hope they have), he'll find a fair percentage of them still outstanding.

        But like I said... hopefully they've changed their definition of "fix".

        On 1/7/05, David Litchfield wrote:
        > Some of Oracle's "fixes" simply attempt to stop the example exploits I sent
        > them for reprodcution purposes. In other words the actual flaw was not
        > addressed and with a slight modification to the exploit it works again. This
        > shows a slapdash approach with no real consideration for fixing the actual
        > problem itself.

        > As an example of this, Alert 68 attempts to fix some security holes in some
        > triggers; the flaws could allow a low privileged user to gain SYS privileges
        > - in other words gain full control of the database server. The example
        > exploit I sent to Oracle contained a space in it. Oracle's fix was to ignore
        > the user's request if the input had a space. What Oracle somehow failed to
        > see or grasp was that no space is needed in the exploit...

        > Here is another class of thoughtless "fix" implemented by Oracle in Alert
        > 68. Some Oracle PL/SQL procedures take an arbitrary SQL statement as a
        > parameter which is then executed. This can present a security risk. Rather
        > than securing these procedures properly Oracle chose a security through
        > obscurity mechanism. To be able to send the SQL query and have it executed
        > one needs to know a passphrase. This passphrase is hardcoded in the
        > procedure and can be extracted with ease. So all an attacker needs to do now
        > is send the passphrase and their arbitrary SQL will still be executed...

        > In other cases Oracle have simply dropped the old procedures and added new
        > ones - with the same vulnerable code!

        > ... In those
        > cases where a flaw was fixed properly, we find the same flaw a few lines
        > further down in the code. The DRILOAD package "fixed" in Alert 68 is an
        > example of this; and this is not an isolated case. This is systemic. Code
        > for objects in the SYS, MDSYS, CTXSYS and WKSYS schemas all have flaws
        > within close range of "fixed" problems. These should have been spotted and
        > fixed at the time.

        Original Litchfield rant (it's a jaw-dropper if you've never read it) -
        http://groups.google.com/group/mailing.unix.bugtra q/browse_thread/thread/b0c60e7ad7b40a90/f18b63bdb4 4470d7?lnk=st&q=litchfield+oracle+bugtraq&rnum=17& hl=en#f18b63bdb44470d7 [google.com]

        Further down in the thread...
        19-jul-2005 - Advisory: Various Cross-Site-Scripting Vulnerabilities in Oracle Report (Not fixed after 700+ days)
        19-jul-2005 - Advisory: Read parts of any XML-file on the application server via Oracle Report (Not fixed after 700+days)
        19-jul-2005 - Advisory: Read parts of any file on the application server via Oracle Report (Not fixed after 700+days)
        19-jul-2005 - Advisory: Overwrite any file on the application server via Oracle Report (Not fixed after 700+ days)
        19-jul-2005 - Advisory: Run any OS Command via uploaded Oracle Report from any directory (Not fixed after 700+ days)
        19-jul-2005 - Advisory: Run any OS Command via uploaded Oracle Forms from any directory (Not fixed after 700+ days)
        • by dwandy ( 907337 ) on Friday October 20, 2006 @06:56AM (#16514355) Homepage Journal
          I for one am tired of major vendors that don't fix problems.
          Business only understands one thing: money. So this needs to cost them money.

          So to me the solution is simple: Researchers privately disclose bugs to the vendor along with a Public Release Date....maybe 6-weeks in the future. Non-Negotiable.
          Fixed or not*, the bug is fully and publicly disclosed on that date. Since OSS (and MS DRM! heheh) has shown that bugs can be fixed in days or at the most a few weeks this should give a motivated company plenty of time to fix it. And only money motivates a business.

          When vendors start getting threatning calls/letters from their customers (either to sue or jump ship) due to unpatched exploits that are public knowledge then they will be forced to fix them.

          Oh sure, the vendors will cry foul (and sadly some will probably try and sue researchers instead of fixing their problems) but the fact is that if one person can find an exploit then a second person can find this exploit. And the other guy might not have noble intentions. Every day that a findable exploit exists is a day that the system is at risk...

          *This is actually important, b/c if you read the rant you'll note that the 'fixes' are half-assed. I'm pretty confident that if the exploit was going to be made public that the fixes would be more robust...or the company will go bust.

          • by linuxmop ( 37039 )
            I agree with you except for one point: 6 weeks is much too long. The correct time to wait is zero days. Here's why:

            1. Vendors need an incentive to write bug free code. If vendors know that they can get away with sell-then-patch, they will do just that. But if bugs mean public exploits, angry users, and bad press, they will spend more money on security.

            2. Black hats often have the security hole before you. So you're not doing the vendors much of a favor by giving them six weeks; you're just shielding th
            • by dwandy ( 907337 )
              well ... 6-weeks might have been too long (I'm no expert) but...

              Vendors need an incentive to write bug free code

              I think most people agree that writing 100% bug free code is impossible. Basing a plan on the impossible is seldom a good idea.

              Black hats often have the security hole before you.

              Yup. In the current 700+ day scenario it's easy for this to be true. Shorten the time line and this will be dramatically reduced.

              those six weeks are six more weeks that a user is susceptible to damage without any chan

To the systems programmer, users and applications serve only to provide a test load.

Working...