Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Bug

Sun Security Patch Introduces Security Hole 265

Posted by CowboyNeal from the patches-for-patches dept.
Rich0 writes "Sun is announcing that their 'Security Hardening Package' for their Cobalt RaQ 4 Linux servers allows remote users to execute arbitrary code. Ironically, the solution is to remove the package, potentially removing protection from other compromises. There's a CERT advisory, as well as an article posted on Extremetech." Yikes, one would hope there's a forthcoming patch in the works.
This discussion has been archived. No new comments can be posted.

Sun Security Patch Introduces Security Hole More

Sun Security Patch Introduces Security Hole

Comments Filter:

  • Big Honking Deal! (Score:4, Insightful)

    by svvampy ( 576225 ) on Friday December 13, 2002 @02:36AM (#4878570)

    Bugs happen every day.

    Patches are generated in response to those bugs

    Patches sometimes generate further bugs

    Sometimes these bugs involve security. D'oh

    profit?

    • Yeah, not really much to discuss on this one. Hopefully they will come out with another patch soon. How long was the bad patch out before they realized the problem?
    • "Bugs happen every day.

      Patches are generated in response to those bugs

      Patches sometimes generate further bugs

      Sometimes these bugs involve security. D'oh"

      Too bad every time MS does it, Slashdot has a 'everybody who uses MS is stupid!' field day.

    • Patch Testing (Score:4, Insightful)

      by anonymous cupboard ( 446159 ) on Friday December 13, 2002 @04:10AM (#4878913)
      During a release test, you run through everything so all possible interactions are checked. This takes some time. A patch is something that gets rushed out to cure a problem in the field. It gets checked to see whether it fixes the bug but there is usually insufficient time to run it through a complete regression test. End result is that patches may introduce bugs.

      Another issue is that sometimes to fix a bug, a newer version of a code block may be used (like taking a Linux 2.5.x solution back to fix a bug in 2.4.x). This code block may have unwanted functionality (because it has been inadequately tested).

      Now all the above goes for commercial software, where there is a formal testing and 'fixit' budget. It therefore goes for free software too. Although individual teams are well motivated to sort out their software, it is more difficult to organise proper testing across teams.

      In this case, we are lucky as a single team are working on this and it was sorted out quickly. Somehow some closed source developers don't seem to be so good about quick releases of their patches, and when they do, they still contain as many bugs (IE patches anyone?).

    • The point: Closed source == No workaround (Score:4, Informative)

      by Morgaine ( 4316 ) on Friday December 13, 2002 @05:02AM (#4879087)
      I think people may have missed the point of this article, which is that Sun say that there is no workaround for the hole.

      If it is true that the vulnerability is caused by a flaw in the input validation of a CGI (common gateway interface) script, and yet there is no workaround other than removing the Security Hardening Package, this implies that the CGI validation script (overflow.cgi) is not available for modification, so regardless of what license this is under, it's effectively not open source, otherwise there would be a workaround.

      Well, we hardly need reminding of that in this forum, but perhaps somebody should make this point to ExtremeTech and to Sun. The CERT advisory rather oddly avoids this point as well, despite identifying the flawed component. It probably just shows that a company's inflexible procedures (package updates in this case) can effectively close even a theoretically open platform like the RaQ.
      • If it is true that the vulnerability is caused by a flaw in the input validation of a CGI (common gateway interface) script, and yet there is no workaround other than removing the Security Hardening Package, this implies that the CGI validation script (overflow.cgi) is not available for modification, so regardless of what license this is under, it's effectively not open source, otherwise there would be a workaround.


        There are workarounds though including removing the offending package. This is NOT Solaris, it's just a Linux distribution on the Cobalt RaQ. In my honest opinion though I would no longer recommend a Cobalt RaQ to anyone anymore since Sun bought the company. They have gone downhill and patches take months to come out. We didn't get a patch for the Apache ROOT EXPLOIT for over 2 months! Thankfully there is a dedicated community that helps to support the product and there was a workaround using the mod_blowchunks, or you could recompile Apache yourself, but then why pay $4k for an appliance if you're compiling shit? I could just get a $500 x86 box and install Debian on it. Anyway, when it comes time to replace the raq4's I guess we'll just have to hack together scripts to do everything the RaQ did as far as GUI administration or maybe try one of those packages.

    • Bugs happen every day.

      Are you insinuating we should just ignore bugs from now on? Especially one that "allows remote users to execute arbitrary code". Seems newsworthy to me, even if it's not a Microsoft bug.
    • Bugs happen every day.

      A bug is a bug is a bug.
      Not.

      Microsoft bugs happen every day.
      Open Source bugs happen. The scurrying around may be somewhat disorganized, but the job gets done, rather well and rather quickly actually.
      Sun bugs do happen, but not that often. "Sun Security Patch Introduces Security Hole" is a pretty rare phenomenon, and even thou I don't use Sun gear, I do want to hear about it. Loud and Fast.
      • Sun bugs do happen, but not that often. "Sun Security Patch Introduces Security Hole" is a pretty rare phenomenon, and even thou I don't use Sun gear, I do want to hear about it. Loud and Fast.

        Have you ever actually managed a patching system for solaris? It's god aweful. At my last job I ended up writing a suite of scripts that managed all our patching and even then the patching was troublesome as numerous patches broke other things.

        Sun currently has a bug in 108940-45 through -48 that they haven't fixed, and then they haven't made the last good version of the patch available.

        As of two years ago sun had over 4GB of patches.

        Half the problem is that everything is managed individually, so a lot of people don't actually patch until they have a direct need to do so, ie something doesn't work or they get attacked. It's too difficult to apply the latest patches and then make sure nothing was broken. I've been burned several times by sticking with the latest patches. It can easily take half of a full time employees time to keep a mmodestly sized network patched.

        I'm not saying anyone is better off, but sometimes more is less.

        -shane
    • Which is precisely why security patches should NOT be mandatory (as some folk have suggested they be). Sometimes the cure is worse than the disease.

  • Well take a look people...

    MS: doesn't release bug fixes because their are no bugs. Only security updates and service packs to appease people.

    Sun: releases a bug fix with an even bigger bug.

    Linux: released bug fixes quickly.

    And that's it, linux will forever be in last because of the fact they can't follow simple rules. You would think that everyone had a copy of Linux's source the way bugs are spotted and fixed so quick .. sheesh. Perhaps we should try and sell the source of linux to India?

    PS - that was sarcasm ...

  • Man speaking to cylist by roadside (Score:5, Funny)

    by kfg ( 145172 ) on Friday December 13, 2002 @03:30AM (#4878778)
    "What on *earth* are you doing there?"

    "I'm ripping the patch off this inner tube."

    "You're taking the patch off? Whatever for?"

    "Well, you see, it's got this big hole in it."

    "Ummmmmmmmm, are you *sure* you know what you're doing?"

    "Don't worry, I can patch the patch when I get home and then nail it back on."

    KFG
  • as a proud owner/admin of a Cobalt Raq2, i'd like to announce that this is not the end of the world to us, no matter how bad it looks on the front page of /.

    that particular machine runs a custom rolled distro of Red Hat 6.2 and has been known to be very reliable, and have mild issues from updates. every one of the holes it covers has some sort of workaround, which those admins have probably employed already.

    i'd like to take this opportunity to complement the Cobalt Raq Users List members as well. without people like bruce timberlake, jeff lasman, steve werby (a /. contributor) and a whole host of others (can't name everyone) the raq has a vibrant community of admins willing to help even the newbiest of owners.

    my machine runs on a lovely 64-bit mipsel processor from MIPS and is one of the dutch (sun bought cobalt a while back, it started on the other side of the pond) original models. they are tremendously power efficient, quiet and dependable boxen. mine uses a dinosauric 2.0 kernel and modified red hat 5.1 , and runs php 4.1.2/mysql like a champ.

    not only that, but the cobalt raq IS a web appliance. In other words, its not really meant to do all that out of the box (back then anyway). today's raqs run a full gamut of oss and free software, and come pre-installed with everything you need as a webmaster.

    it is an oustanding machine for NT admins to learn how to switch over, with the cushion of a working system to learn from.

    yes, sun doesn't always get it right, but they put their backs into it so to speak, and it is not unusual for a Cobalt engineer to post solutions (even unofficial ones) to the list.

    for all you cobalt users out there, you know what i'm saying, and if you're not on the list, you're missing out.

    this post has voided your warranty. peace.

    • I used to have a RaQ2. One of the nice things about it was the oddness of having the Mips R4000 - most of the remote root exploits that the skript kiddies used were Intel-only. I still kept it patched though!

      My only real gripes with it was that it was awfully hard to get a lot of stuff to compile (there was only ever one version of OpenSSH which would build cleanly, and getting a new version of gcc going was a real pain) and although it was perfectly adequate for PHP and MySQL and the usual Apache stuff (oh, and PHP didn't work out of the box either, it died with a floating point exception without patching) it was HORRIBLY slow for Perl and Perl cgi scripts. If you had a single "use" Perl statement in your perl script, the Perl script would take 3 to 4 seconds to start using 100% CPU. I never did find a fix for that problem.
    • If I recall correctly, the original SHP was not even released in response to a specific vulnerability, but as the name implies, was a package intended to provide general "hardening" against unspecified and/or unknown exploits. Most/many savvy server operators had already applied the fixes retail. If you want to slam Sun/Cobalt on this one, I think you'd be better off picking on them for implying that an out-of-the-box server appliance is secure as shipped, rather than requiring some careful attention. The cobalt-users list makes that point quite regularly - and constructively.
      • you're absolutely right about that, would be nice for them to ship more secure out of the box, and we do comment the hell out of that. unfortunately, making such an important point has not won you admiration from the moderators.
        therefore i regret to inform you that your cobalt warranty has been irrevokably voided.
    • i'd like to take this opportunity to complement the Cobalt Raq Users List members as well. without people like bruce timberlake, jeff lasman, steve werby (a /. contributor) and a whole host of others (can't name everyone) the raq has a vibrant community of admins willing to help even the newbiest of owners.
      Well while you're doing that I'd like to thank the NetBSD folks for ensuring that I don't have to worry about any more vendor lock-in on Cobalt's MIPS hardware. Cobalt has a horrid history of providing security updates for their products. Sun's purchase didn't really improve that by any appreciable margin. For their x86 stuff it wasn't that hard to just install your favorite distribution, though it did involve some kernel patching. For the MIPS stuff, NetBSD is the only real answer if you want to stay current and secure. (unless its a qube 2700 in which case your best corse of action is currently buying some dirt and turning it into a planter) BTW, while the RM5231 is 64bit capable its run in 32bit mode.

  • There is a patch already (Score:5, Informative)

    by lifeless ( 322541 ) <rbtcollinsNO@SPAMhotmail.com> on Friday December 13, 2002 @03:38AM (#4878799) Homepage
    Has *anyone* actually read the SUN announcement.

    I quote:
    ===
    5. Resolution

    This issue is addressed in the following releases:

    Intel

    * http://ftp.cobalt.sun.com/pub/packages/raq4/eng/Ra Q4-en-Security-2.0.1-SHP_REM.pkg or later
    ===
  • At least they make aware the glaring weakness in their merchandise. The fact that you have to remove the patch to get rid of the weakness, yet open up others is irrelevant. Any knobhead with an IQ higher than his inseam can figure out away to get around this security hole themselves.

    Aside from that, every patch in and of itself is a glaring security hole. You don't think that by examining the code in the patch you can get a general idea for how the program itself works? That's how most weaknesses are found (by the slinky malicious cracker anyway).

    It all comes down to the Admin. For if he is well-minded and concerned greatly with security, none of the security holes we learn about would have much chance of being used against you.

  • Exploits out in the wild, first victims show up (Score:4, Informative)

    by decarelbitter ( 559973 ) on Friday December 13, 2002 @04:03AM (#4878899)
    Exploits for this vulnerability are already all over the internet, and the first boxes have been hacked. Just yesterday I read in a newsgroup that a Dutch ISP had a box cracked, probably because of this hole. So if you own a RaQ please take some extra care and look twice if you're safe.

  • Official patch (Score:4, Informative)

    by almaw ( 444279 ) on Friday December 13, 2002 @05:17AM (#4879139) Homepage
    Oh, please read the damned advisories before claiming things that aren't true...
    The official solution is not to remove the whole package, but to install this patch:

    http://ftp.cobalt.sun.com/pub/packages/raq4/eng/Ra Q4-en-Security-2.0.1-SHP_REM.pkg [sun.com]

    Note that it's a flaw in the admin site scripts that causes this problem. So if you don't use that and have disabled it, then no problem. :)

    • Re:Official patch (Score:2, Informative)

      by almaw ( 444279 )
      Whoops. :)
      Just let me eat my own words before I get flamed. Yes, I've just realised that that patch is actually a shell script which removes the original package. Hmmm...

      Surely you can just remove the offending CGI script instead?
    • Now, THAT is funny and made even more so by the fact that I have done the same thing. (Damn. That preview button is too close to the Submit Button!!!) Feels kinda like an octupus stomach-ache. You know, where the octopi stomach, the one the comes OUT to get the food, rather than wait paitently for whatever's gonna drop down the pipe, picks up a rock with all those spiky edges. Yuck, yuck, yuck.
  • A maintainance release for Solaris 8 enabled additional features in BIND 8 which were known to be vulnerable at the time the maintainance release was shipped. Previous versions lacked the feature and thus the vulnerability.

    Of course, this was much more dangerous than the current case because it had already been claim that Solaris 8 was not affected by that BIND bug.
  • In september a few pages belonging to Norwegian police were hacked, among those www.okokrim.no - the unit that indicted Jon. They seem to have moved their sides to a Cobalt server, in New York, it seems ... Ready! Aim! Hack!

  • Anyone who's been a Sun administrator has seen Sun screwup patch packages (breaking something during the fix). This is not news. What is going to happen is that in a week or two (or months, depending on the severity or difficulty to fix), Sun will release yet another patch package that will resolve the issue.

    So if you put it in, back it out. Devise your own workarounds if you think its a significant vulnerability. Security is established through design and monitoring. Firewalls, subnets, switches, ssh, checksums, login authentication, log monitoring. You can't rely on vendors to resolve your security issues. Companies can only fix the security holes that they are aware of. You're only screwed when you're stuck with an improperly designed legacy system or policies that can't be defended. But that's not Sun's fault.

  • If a piece of software doesn't work right or introduces severe security issues, simply remove it until it is corrected.

    It's a good thing that OS developers are smart and would never be so stupid as to develop an OS that would require a high security risk software, like a browser, just to run. An OS has to be modular and highly configurable in order to do that, and that always makes more sense than a monolithic beast.
  • The "Security Hardening Package" makes security harder (to implement). For some reason, I'm suddenly reminded of Marvin Martian's "ACME Disintegrating Pistol".
  • Yikes, one would hope there's a forthcoming patch in the works

    Isn't that this whole thing got started in the first place? Instead of a security patch they should release a "zero security" patch. If they're consistent, using the powers of reverse psychology it will be the most secure system ever developed.

  • that OS's commonly in use today were originally created for functionality and hardware support, not for "security", and that the foundational structure of these OS's (if not the code itself) predates the advent of the ubiquitous Internet. Trying to shoehorn security into them as an afterthought is often like trying to fit a round peg into a square hole.

    The question is, will this unceasing paranoia about "security holes" lead to better software, or terrible software?

  • See? (Score:3, Funny)

    by Hubert_Shrump ( 256081 ) <[cobranet] [at] [gmail.com]> on Friday December 13, 2002 @12:44PM (#4881856) Journal
    I so told you that Microsoft was a trend-setter.

    You owe me a buck, man.


  • Here it is: Ø

    If you find a bug or want additional features, just submit a report and we'll fix it and issue a patch.
  • Dear Emily:
    I recently read an article that said, "reply by mail, I'll summarize."
    What should I do?
    -- Doubtful

    Dear Doubtful:
    Post your response to the whole net. That request applies only to
    dumb people who don't have something interesting to say. Your postings are
    much more worthwhile than other people's, so it would be a waste to reply by
    mail.
    -- Emily Postnews Answers Your Questions on Netiquette

    - this post brought to you by the Automated Last Post Generator...

Slashdot Top Deals

It's been a business doing pleasure with you.

Close