Forgot your password?
typodupeerror
Security Bug Upgrades

Multiple Vulnerabilities in OpenSSL 274

Posted by CowboyNeal
from the stay-safe-stay-current dept.
gfilion writes "Updated versions of OpenSSL are now available which correct two security issues: A null-pointer assignment during SSL handshake and an out-of-bounds read that affects Kerberos ciphersuites. Full advisory available on OpenSSL site and US-CERT."
This discussion has been archived. No new comments can be posted.

Multiple Vulnerabilities in OpenSSL

Comments Filter:
  • News at 11

    Honestly people, is this really /. front page news? This came out on the FreeBSD mailing list 36 hrs ago, and a fixed version of OpenSSL is already available.

    CVSup; make buildworld && make installworld

    Problem solved.
    • by BlueCodeWarrior (638065) <steevk@gmail.com> on Friday March 19, 2004 @12:04AM (#8606591) Homepage
      For those of us not on the FreeBSD mailing list, it is.
    • Yes, but *BSD takes security in general a lot more seriously.

      Rather than racing around trying to be all things to all people, the *BSD developers concentrate on what they are good at: developing a darn good server OS.

      For your average Linux user, this will be treated as a nuisance that interrupts them trying to get the latest unstable kernel compiled, for your average *BSD user, this is important stuff that affects the security of their IT infrastructure.
      • by Anonymous Coward
        Wow, aren't we pretentious and elite today? I could just as easily say that the average Linux user just waits for cron-apt or something similar to pull in the fixed packages when they are made available by their distribution, which is a far more realistic claim, yet equally as handwaving and vacuous as the one you made.

        Get a life.

    • by stratjakt (596332) on Friday March 19, 2004 @12:11AM (#8606635) Journal
      It's certainly front page news if there's a non-exploitable flaw in Windows for which a patch has been released.

      cvs, make and build sure.. But when it's click windows update, somehow it's some monumental task thats just the worst thing imaginable.
      • by Sivar (316343) <charlesnburns[&]gmail,com> on Friday March 19, 2004 @01:17AM (#8606999)
        You have a good point, as using Windows Update is easier (or at least as easy) as any GNU/Linux update method, and can be made automatic very easily (like some GNU/Linux update methods).
        One noteworthy difference, however, is that none of the BSD or GNU/Linux update methods tell the vendor the software (and their versions) that you run [petri.co.il]. To their credit, at least, none of them (including Microsoft) collect any actual personally identifiable information.
        • by NightSpots (682462) on Friday March 19, 2004 @03:15AM (#8607479) Homepage
          Never used RHN, have you?

          First thing it does is `rpm -qa` and sends that list right to RedHat.

          It's really hard to know what updates to provide without seeing a list of software packages installed. Sure, they could differentiate between "Our" software and "Other" software in the list of installed programs, but that's just silly - send the whole list, and ignore the stuff you don't care about.
          • It's really hard to know what updates to provide without seeing a list of software packages installed

            That's the nice thing about Gentoo. I recieve the full software tree everything I emerge sync so only *I* know what I have installed.
        • You have a good point, as using Windows Update is easier (or at least as easy) as any GNU/Linux update method, and can be made automatic very easily (like some GNU/Linux update methods).

          Windows Update consists of at least 4 click-then-wait-a-while cycles before your software is updated, and several packages must be installed separately (MSIE, service packs, DirectX, etc). On Debian, at least, you can run one command (apt-get update && apt-get -y upgrade) that will often complete the entire upgr

      • But when it's click windows update, somehow it's some monumental task thats just the worst thing imaginable.

        Well, Windows Update pretty much always insists on rebooting the machine, which is irritating to some users (i.e. power users). On *nix this only needs to be done for (fairly rare) kernel exploits and not simple library/program updates.
    • by MobyTurbo (537363) on Friday March 19, 2004 @12:13AM (#8606655) Homepage
      Honestly people, is this really /. front page news? This came out on the FreeBSD mailing list 36 hrs ago, and a fixed version of OpenSSL is already available.

      Slackware Linux [slackware.com] also has this fixed. Incidentally, like the parent's subject line says, this is a minor vulnerability that at the most makes openssl crash, not an exploit or a trojan like all the stuff we've been seeing about Windows on /. lately.

    • by KidSock (150684) on Friday March 19, 2004 @12:14AM (#8606660)
      ...is this really /. front page news? This came out on the FreeBSD mailing list 36 hrs ago.

      Yes. Most of us are not on the FreeBSD mailing list. Instead we wait for the more mainstream outlets like ./ to report the problem. Also it's good to wait about 36 hours or so for the fix to go through the motions as the sudden intrest rattles free other problems.
    • by ewhac (5844) on Friday March 19, 2004 @12:25AM (#8606733) Homepage Journal

      CVSup; make buildworld && make installworld

      For people who've never done this before (such as myself), this is an intimidating operation; care to walk me through it? It also glosses over insignificant little details, such as:

      • How do you set up your supfile?
      • Over a period of several updates, how do you avoid having stale libraries/executables/config files scattered all over your machine?
      • Is there a risk that 'make installworld' will silently overwrite a functional replacement previously installed from ports? (E.g. I'm using postfix, thankyouverymuch, and don't want sendmail to reappear.)

      Dumb questions I'm sure, but the answers have never been revealed in a form I can understand.

      Schwab

      • by Anonymous Coward on Friday March 19, 2004 @12:38AM (#8606791)
        How do you set up your supfile?

        Copy it from /usr/share/examples/ (it's somewhere in there, I think, my FreeBSD box isn't running at the moment, I've poached some of its hardware).

        Over a period of several updates, how do you avoid having stale libraries/executables/config files scattered all over your machine?

        That's a fine question indeed. What I do is:

        make DESTDIR=/usr/local/fake_root distrib-dirs distribution

        make DESTDIR=/usr/local/fake_root installworld

        make DESTDIR=/usr/local/fake_root installkernel KERNCONF=foobar

        Then you can compare the contents of /usr/local/fake_root and stuff in /. I like find and sort and vimdiff to do that. It's not super elegant, but you don't have to do it too often if you're tracking something like RELENG_4_9, since rarely do things get updated. What you would use it for is when you make changes to the base, which leads me to:

        Is there a risk that 'make installworld' will silently overwrite a functional replacement previously installed from ports?

        Yes! But you can get around it. In /etc/make.conf, do:

        NO_SENDMAIL=true

        Now sendmail won't be built, although its stale files will hang around; refer to point 2 above.

        You'll also, in rc.conf, want:

        sendmail_enable="YES"

        sendmail_flags="-bd"

        sendmail_outbound_enable="NO"

        sendmail_submit_enable="NO"

        sendmail_msp_queue_enable="NO"

        At least for Postfix, which you say you use.

      • by Electrum (94638) <david@acz.org> on Friday March 19, 2004 @01:23AM (#8607028) Homepage
        For people who've never done this before (such as myself), this is an intimidating operation; care to walk me through it?

        First, RTFM:

        http://www.freebsd.org/doc/en_US.ISO8859-1/books/h andbook/cutting-edge.html [freebsd.org]
        http://www.freebsd.org/doc/en_US.ISO8859-1/books/h andbook/makeworld.html [freebsd.org]

        I run 4-STABLE on all of my boxes, so this will be a bit different for 5. Create /etc/make.conf. You can look at /etc/defaults/make.conf and in the handbook for more details:

        CFLAGS=-O -pipe
        NOPROFILE=true
        NO_BIND=true
        NO_SENDMAIL=t rue

        SUPHOST=cvsupXX.freebsd.org
        SUP_UPDATE=yes
        SUP =/usr/local/bin/cvsup
        SUPFLAGS=-g -L2
        SUPFILE=/usr/share/examples/cvsup/stable-supf ile
        PORTSSUPFILE=/usr/share/examples/cvsup/ports- supfi le


        Replace SUPHOST with your CVSup mirror. See the handbook [freebsd.org] for more info. The NO_BIND and NO_SENDMAIL lines keep buildworld from building BIND and Sendmail, respectively, since I use djbdns and qmail.

        Once you have setup /etc/make.conf, you can update the source tree by doing this:

        # cd /usr/src
        # make update


        That will also update /usr/ports. If you want to just update ports, run make update from /usr/ports.

        Once your source tree is up to date, update the system following section 21.4.1 in the handbook. I skip the single user mode part, since I do everything over SSH:

        # mergemaster -p
        # rm -rf /usr/obj/*
        # make -j4 buildworld
        # make -j4 buildkernel
        # make installkernel
        # make installworld
        # mergemaster -i
        # reboot


        The order there is important. The kernel should be built after the world is built, since building the world updates the build tools (this is especially important when it has been a long time since you last updated). The kernel should also be installed before the world is installed.

        You should almost always update the kernel when you update the world. If you choose not to reboot immediately after installing the new world, you might notice that tools like ps no longer work, since they don't match the kernel.

        These is how I do things after several years of experience. Make sure to read and understand the handbook before doing anything. But really, it's not that hard, especially after you do it a few times.

        An unrelated but very useful tip: check out the sysutils/portupgrade port.
      • advice on cvsup (Score:4, Insightful)

        by puzzled (12525) on Friday March 19, 2004 @02:33AM (#8607339) Journal

        There is a minimal cvsup config for FreeBSD 4.9 - cvsup -g -L 2 and you're off and running.

        *default host=cvsup6.FreeBSD.org
        *default base=/usr
        *default prefix=/usr
        # The following line is for 4-stable. If you want 3-stable or 2.2-stable,
        # change "RELENG_4" to "RELENG_3" or "RELENG_2_2" respectively.
        *default release=cvs tag=RELENG_4
        *default delete use-rel-suffix
        # If your network link is a T1 or faster, comment out the following line.
        *default compress
        src-all
        #ports-all tag=.

        make buildworld & make installworld install *world*, which does not include anything you built out of /usr/ports - portupgrade is what handles moving that stuff forward for you.

        FreeBSD *is* intimidating at first, but if you take the thirty days of pain at the end of that time you'll be looking at your Linux boxes and wondering why you ever put up with the chaos ...

      • Yeah, quite. It was this very shitfight that had me over to Debian about two years back.

        Haven't looked back since.

        Dave
      • by cperciva (102828) on Friday March 19, 2004 @03:50AM (#8607589) Homepage
        CVSup; make buildworld && make installworld

        For people who've never done this before (such as myself), this is an intimidating operation; care to walk me through it?


        If you're intimidated by buildworld, there's an easier option:
        # freebsd-update fetch
        # freebsd-update install
    • by gad_zuki! (70830) on Friday March 19, 2004 @04:47AM (#8607775)
      >Honestly people, is this really /. front page news?

      Yes, lets just wait till some kiddie write a worm that crashes thousands servers all over the world and then post about it.

      I like that slashdot posts security problems. Why?

      1. For the lazy admin. Theres lot of them.

      2. because its important to keep reinforcing the idea that computers suck (I dont care what OS you like) and need constant care.

      • 1. For the lazy admin. Theres lot of them.

        [Raises hand.]

        I know security is important, but I know time is finite.

        Slashdot stories like these are kind of like

        $ grep important bugtraq freshmeat
        Sure you could monitor the raw feeds and find out earlier and in greater detail, but that takes time and attention away from other stuff.
  • 3 actually (Score:5, Informative)

    by chrisopherpace (756918) <cpace@@@hnsg...net> on Thursday March 18, 2004 @11:58PM (#8606546) Homepage
    According to this link
    Here [uniras.gov.uk]
    There are three vulnerabilities.
    This was, like, sooo yesterday on the Bugtraq lists ;)
    • by Anonymous Coward on Friday March 19, 2004 @12:01AM (#8606562)
      Let me summarize this whole thread so we don't waste anytime:

      Microsoft fans - "see, Linux/FOSS have security issues too"

      Linux fans - "yeah, but we fixed this right away. If this was Microsoft, we would have been waiting for months"

      Repeat again and again..

      Netx topic please..
      • Re:3 actually (Score:4, Informative)

        by chrisopherpace (756918) <cpace@@@hnsg...net> on Friday March 19, 2004 @12:13AM (#8606652) Homepage
        Not to troll, but OpenSSL is not Linux, and Linux is not OpenSSL.
      • by Anonymous Coward
        hate to troll either but all the Microsoft fans on slashdot are Microsoft Employees. I know this because I am one. I am too ashamed to admit it in public but hay, the pay is great.
      • by fermion (181285) on Friday March 19, 2004 @12:54AM (#8606890) Homepage Journal
        Anyway we all know the problem isn't MS, the problem is C. It is such a 1970 type of language. Back when programmers were randomly jumping from place to place, casting memory as whatever type of data pleased them, recasting the data in function calls, copying blocks of data without a care of whether the blocks really existed, and, in this case, assigning NULL pointers all willy nilly. I mean really. No programmer educated in the past 15 years actually has the skill to remember that the void pointer pointer which in the last call has the value of the beginning of a three dimensional array, now points to the beginning of four dimensional array, which, of course, is complicated by the fact that such beasts only exist in the mind of the programmer, and not in any specific language construct, pointer math being one of those fictional things beat into the heads of the unfortunate programmers trained 20 years ago. And let's not even talk about the infinite loop idiom.

        Anyway, we need to rewrite the entire thing in the elegant languages of the 21st century. I suggest this [slashdot.org]

        • I've often thought that refactoring the Linux kernel in Haskell would be rather nice.

          C is the devils tool.
        • I have some problems with its lack of language features, but for security-critical components memory safety, configurable security settings and controlled crashes (exceptions that can be caught and terminate just one thread) can not be beat. sshd should be written in Java, at least as an option for extra security, with as little native code as possible.
        • are you willing to take the performance hit to convert it to another language though?

          c is just one step away from being a macro assembler, so it's very fast. it's suitable for writing hardware device drivers, something most other languages are not. you won't be seeing any gigabit ethernet drivers written in java, for example. unless you want your gigabit ethernet driver to perform like 10mbit :-)

          the reason there's pointers, etc. is because that's the way CPUs operate. C being such a lowlevel language inhe
        • Damn, do I ever feel old right now.
          I understand pointer math. I know how to use (and indeed, have used) 4-dimentional arrays of complex data types, and I've written an infinite loop intentionally (the trick is to use an external event to change the otherwise-infinite boundry condition)
          The fun one is taking a pointer to a one-character array, then when you know what size your objects are going to be, cast the pointer to a pointer of the correct size, then do pointer math on a big chunk of memory to build
        • In this case, no, the problem isn't C. The bugs all involve dereferencing a null pointer, which will kill a Java program just as surely as it will call a C program. (Yes, you can catch NullPointerException in Java; you can also handle SIGSEGV in C. That doesn't mean you can provide a useful recovery path from such an unexpected event.)
    • Re:3 actually (Score:5, Informative)

      by Siva (6132) on Friday March 19, 2004 @12:02AM (#8606576) Homepage Journal
      true, but one was in an older-than-current version. not to say it shouldn't be noted, of course...
  • by barfarf (544609) on Thursday March 18, 2004 @11:59PM (#8606556)
    I think we should be like Microsoft and not tell anyone about it until it's already patched.

    ... oh, wait....

    • by Trejkaz (615352) on Friday March 19, 2004 @12:04AM (#8606588) Homepage
      But remember, according to Microsoft the exploits can't exist until after the patch is released anyway.
    • by thedillybar (677116) on Friday March 19, 2004 @12:12AM (#8606646)
      They didn't tell anyone until a patch was available. Note that the vulnerability was announced Wednesday, and it included a link for the patch (openssl-0.9.7d) when it was released.

      It's fairly reasonable to assume that the developers knew of the vulnerability some time before the new version became available.

      I think it's good practice to do this if you can develop the new version fast enough. Announcing it early is only inviting someone to exploit it. I doubt anyone will fix the vulnerability themselves and put it into production before the official release comes out.

  • Actual Threat? (Score:2, Interesting)

    by Anonymous Coward
    Already updated, but (w/o Kerberos) could this actually lead to anything more than the crashing of sshd and httpd child processes (assuming that's all one's using OpenSSL for)?
    • Re:Actual Threat? (Score:2, Interesting)

      by $0 31337 (225572)
      Well I suppose that the answer is no considering that the CERT Advisory, OpenSSL site, Other numerous sites say "This can lead to a DoS attack" and don't mention anything else. RTFA.
  • by contrasutra (640313) on Friday March 19, 2004 @12:04AM (#8606590) Journal
    Please don't comment "so I guess Windows isn't so insecure, is it...". We always seem to get a few of these. OpenSSL/OpenBSD has a VERY good security track record. Is a vulnerability a problem? Yes, but when MS has OpenBSD's track record, you can compare.

    Also I think this is a good news post simply because it helps to show we're not Anti-windows bias. We report security problems on ALL os's.

    Oh well, sometimes you just have to combat the trolls.
    • by Trejkaz (615352) on Friday March 19, 2004 @12:06AM (#8606600) Homepage
      In particular, if you were running OpenSSH on Windows, which still depends on OpenSSL, then you are still in trouble. This isn't an OS security problem, it's a library security problem.
      • In particular, if you were running OpenSSH on Windows, which still depends on OpenSSL, then you are still in trouble.

        Is OpenSSH affected by this problem? AFAIK SSH doesn't use the SSL protocol. So if SSH just use the cryptographic primitives from OpenSSL, and the vulnurability was in another part of the code, how could SSH be affected?
    • Also I think this is a good news post simply because it helps to show we're not Anti-windows bias. We report security problems on ALL os's.

      Um... Yeah. Because this is where I go for all the breaking news in the HP-UX or AIX world, right? Sorry. Half the crowd is pro-windows biased, half the crowd is anti-windows biased and half the crowd lies by saying they aren't biased either way. You only hear about the OSs that make for a good holy war on /. because if you don't have a bunch of biased zealots ru
      • Half the crowd is pro-windows biased, half the crowd is anti-windows biased and half the crowd lies by saying they aren't biased either way.

        150% of the crowd cannot even use correct percentages, and make subjective opinions on matters they know nothing about :)

        But keep on trucking...you hit quite a few good catchphrases, including but not limited to: pro-windows *3, anti-windows *2, OS *2, zealot, dorks*2, open source, /. * 2, bias *3

    • by doomy (7461) on Friday March 19, 2004 @12:46AM (#8606840) Homepage Journal
      Yes, but when MS has OpenBSD's track record, you can compare.

      This just out from MSFT:
      Only one remote hole in Windows XP, since yesterday.
    • Just to clarify, OpenSSL does not have that great of a security record. In fact a large percentage of the OpenBSD advisories have something to do with it. Theo has been seriously considering forking the project (the OpenBSD team does NOT do OpenSSL).
  • Bullshit... (Score:4, Funny)

    by Anonymous Coward on Friday March 19, 2004 @12:09AM (#8606623)
    Everything is fine, firewall is quiet, and I dont think a single box wiL#%*#AT+H+H[NO CARRIER]

    • by Anonymous Coward on Friday March 19, 2004 @12:28AM (#8606750)
      Please let the 'no proble...[NO CARRIER]' joke die. It is less funny than recursive acronyms, number representation wackiness, or 'yet another' names for programs.

      Okay, maybe not less funny - but just as unfunny.

  • Old news (Score:3, Insightful)

    by macdaddy (38372) on Friday March 19, 2004 @12:22AM (#8606711) Homepage Journal
    I mean this is over a day old now. Why it took CERT so long to send the advisory I don't know.
    • CERT (US-CERT) has been slower since USDOHS got on the scene. They've slowed quite a bit, but maybe they're doing a lot more behind-the-scenes work with organizing patches, releases, and the like.
    • Why it took CERT so long to send the advisory I don't know.

      You're joking, right? A day is flat-out amazing. CERT used to take months to announce stuff. It was a joke; I unsubscribed because at the time, I found out about stuff in updated RPM changelogs well ahead of when I read it in one of CERT's email alerts. They'd often take over a week to send an email out about a virus that had already thoroughly spread.

  • Move along (Score:5, Informative)

    by Dalcius (587481) <chrism3413+slashdotNO@SPAMgmail.com> on Friday March 19, 2004 @12:23AM (#8606716)
    Nothing really to see here folks. Both attacks crash the SSL server, so we're looking at DOS attacks and not 'holes'. This is certainly serious for the business who relies on it, but for home networks and casual use (which I'm sure is common among slashdotters) this is no sweat.

    Nice to hear that they found the holes, though. :)
    • Does this crash the SSL servers or merely tie them up? Anyone have any details? I assume this affects Apache with mod_SSL with an earlier version of OpenSSL, but can you disable Kerberos under Apache temporarily until the lib can be updated?
    • ...when the "home" server I'm logging into is 400km away, it's kinda hard to get back in touch. I'd have to call up my folks and have them hit the reset button, not exactly what they (Did I do something wrong now?), me (Sigh, I have to ask the least technically compentent people for help) or the server (I swear it'll corrupt something important, Murphy's law) wants...

      Kjella
      • Re:No, but... (Score:3, Informative)

        by thogard (43403)
        If you need the program to run, its init's job to keep it running and init does a fine job doing exactly that.

        I guess you start your critical ssl apps out of the rc scripts don't you?

        A well built server can take a # kill -9 -1 and still keep on going. (thats kill -SIGKILL every process)
  • As of the time of this writing, yum repositories for Fedora Legacy 7.2 have does *NOT* have these updates!!!
  • by InvaderXimian (609659) <elvedinNO@SPAMods.org> on Friday March 19, 2004 @12:54AM (#8606891)
    Considering most setups (namely FreeBSD ones) aren't affected because this is a problem with Kerberos ciphersuites and the OpenSSL code is extremely MIT Kerberos specific so this flaw doesn't affect it.

    From the FreeBSD security list:

    If one compiles OpenSSL oneself, *and* has MIT Kerberos, *and*
    > enables the Kerberos options, *and* has all ciphersuites (or at least
    > the Kerberos ciphersuites) specified in your application's
    > configuration, then you might be affected. But that has nothing to
    > do with FreeBSD.
    > Thus, answering your question again:
    >
    > Isn't FreeBSD vulnerable to the second "Out-of-bounds read affects
    > Kerberos ciphersuites" security problem?
    >
    > No, FreeBSD is not.
    • I subscribe to both debian and freebsd security lists. I got my warning from debian a couple of days ago and patched the system and have been patiently waiting for my warning from freebsd. Apparently I should not hold my breath.

      Every day I am so happy I use freebsd. It's truly awsome. Stable as a rock and secure as a safe.
  • What shall I do to protect a RH9 system? Are the rpm updates here [redhat.com] what I need? If so, I assume I need this [redhat.com] and this [redhat.com] -- since they are from 17.March.2004? (the *devel* package is available for i386 only, so that's why it's i386, no i686).

    Thanks.

  • Yawn (Score:4, Insightful)

    by ChiralSoftware (743411) <info@chiralsoftware.net> on Friday March 19, 2004 @02:03AM (#8607219) Homepage
    I'm bored of these OpenSSL advisories. On and on they go. An unchecked null and an out-of-bounds read. Someday, people will realize that unsafe data (anything that comes in over the net) really can't be safely manipulated in a language like C. If OpenSSL had been implemented in Java, there types of errors couldn't exist, or if they did exist, they would throw exceptions which could be caught and handled in some reasonable way.

    Rule #1: Unsafe data should be handled in sandboxed languages.

    Rule #2: Programs that are exposed to unsafe data (server processes) should run at some minimum and constrained privilege level, not as root. The "must be root to bind to ports less than 1024" rule on Unix is almost exactly the opposite of what the rule should be.

    I'm sure many people who don't understand these issues will flame me or say I am trolling, but oh well, someone needs to keep bringing this up until it sinks in.

    ------------
    Create a WAP server [chiralsoftware.net]

    • Re:Yawn (Score:3, Insightful)

      by kobaz (107760)

      Someday, people will realize that unsafe data (anything that comes in over the net) really can't be safely manipulated in a language like C.

      People like you who don't understand that any software written in any language can be exploited should be shot. Your post is just painful to read.

      Rule #1: Unsafe data should be handled in sandboxed languages.

      Rule #1 is actually: VALIDATE ALL USER INPUT

      This holds true for any language, c, java, php, brainfuck, or anything else. You can just as easily explo

      • Re:Yawn (Score:5, Interesting)

        by ChiralSoftware (743411) <info@chiralsoftware.net> on Friday March 19, 2004 @03:20AM (#8607501) Homepage
        No, I'm not trolling. I can summarize your whole post in one sentence: "Don't make mistakes and everything will be fine!" We've been hearing that for years. The best C security coders in the world are the OpenBSD team and guess what, they make mistakes. They fail to validate input sometimes. They have had exploitable bugs in their code. And what are they doing now? They are moving to models like privsep, w^x and systrace which are all forms of sandboxing or hole containment. Eventually if they take that far enough, they'll end up running bufferless code in a VM, which would give me a sense of deja vu.

        Sure, it's entirely possible to write perfect C code with no mistakes, and it's possible to not validate input on Java code and make plenty of mistakes. You gave a great example: SQL injection attacks. Java has some great defenses against that: Use java.sql.PreparedStatement instead of java.sql.Statement. Even better, use something like JDO to give an abstracted OO view of the data.

        Here's where C breaks down: The human mind doesn't think in the right way to use C safely. We can't change the human mind (yet), but we can change which language we use. Humans just don't spot out-of-range errors, for example, but out-of -range errors are all trapped in Java and also because Java collections know their size (unlike C arrays/pointers) out-of-range errors are much more obvious.

        Also, saying that "if you validate your input you can run it at any priv level you want" is just the wrong way to think about this. Mistakes will happen in any sufficiently large system (ie, any system that is large enough to be useful today). The only reasonable thing to do is to contain those mistakes, which means isolate processes and functions.

        Or you can keep on repeating "nothing bad would ever happen if we didn't make any mistakes!" I guess if that's what you think, I can't change your mind.

        • Re:Yawn (Score:3, Insightful)

          by Srin Tuar (147269)
          The problem with VM's is that they are pigs.

          Openssl is coded in highly optimized C, with many components in assembly, and its still considered a high-overhead resource hog and is often the target of hardware acceleration.

          If you seriously think "Java" is even in the running for that workload- then you are seriously deluded. VM's have this peculiar BIG problem: they are slow and resource-intensive. They dont play well with other processes, they cannot swap out to share ram, and they encourage memory bloat.
        • Re:Yawn (Score:3, Insightful)

          by Electrum (94638)
          We've been hearing that for years. The best C security coders in the world are the OpenBSD team and guess what, they make mistakes. They fail to validate input sometimes. They have had exploitable bugs in their code.

          Funny, then why have the qmail [cr.yp.to] and djbdns [cr.yp.to] security guarantees never been claimed? Perhaps because it really is possible to write secure code in C?
    • Rule #2: Programs that are exposed to unsafe data (server processes) should run at some minimum and constrained privilege level, not as root. The "must be root to bind to ports less than 1024" rule on Unix is almost exactly the opposite of what the rule should be.

      Hear, hear. I've always wanted a kernel option to disable that, as I'm the only user on my machines and it would be nicer if I could just run my daemons as non-root than being secure in the knowledge that all of the other (zero) people who have a

      • Re:Yawn (Score:4, Insightful)

        by thogard (43403) on Friday March 19, 2004 @05:07AM (#8607839) Homepage
        Its a one line patch to get linux (2.2 and maybe 2.4 and maybe 2.6) to only let you open ports that equal a group your in. Its a simple fix but no one wants to do it. Even the standard /etc/groups aren't set up for this. Whatever listens to SMPT should be in group 25 and apache should be in groups 80 and 443. Then you don't need root to bind to the port and no other user can bind to the port either.
    • Re:Yawn (Score:3, Insightful)

      by jmv (93421)
      Rule #1: May I remind you that said unsafe data is also manipulated by the kernel and glibc. Are you suggesting those get converted in Java too? Oh, and with a badly written Java app, it's also possible to do all kinds of things (just not buffer overflows).

      Rule #2: Ever heard of "bind to port and then change uid"?

      I'm sure many people who don't understand these issues will flame me or say I am trolling, but oh well, someone needs to keep bringing this up until it sinks in.

      Thanks for enlightening us all.
    • Writing OpenSSL in Java. No.
      Having to be root to bind to ports under 1024. Yes, it's very silly. Why can't we get rid of that hangover now?
      • by kobaz (107760)
        Having to be root to bind to ports under 1024. Yes, it's very silly. Why can't we get rid of that hangover now?

        Because on multiuser systems where you for example don't run a web server you don't want random people poping up a server on port 80 pretending to be you. Of course you could firewall it off, but why not let the kernel take care of it?
    • by bani (467531)
      define "unsafe data".
    • Re:Yawn (Score:2, Informative)

      by iwadasn (742362)
      I completely agree. The port binding should still be specific, but not root. For instance, every unix system should have a "network" user that is the only one that can bind to ports less than 1024, root cannot, nor can anyone else. That nicely sandboxes all the attack vectors into one user that can be easily controlled and chrooted.

      But of course none of this would be necessary if everything possible was written in java. Then you wouldn't really have to worry because worst case scenario, you get an exceptio
  • by veddermatic (143964) on Friday March 19, 2004 @03:54AM (#8607603) Homepage
    When an OSS / Linux / BSD / OS X / something other than Windows flaw is found, it's serious.

    It really is. You need to take it seriously and fix it. ASAP. Hopefully, most folks who run said OSes are paying attention, and will do what they need to do to secure the flaw.

    That said, every time anyone uses Outlook to read email, the above looks really, really good.
  • Redhat? (Score:5, Informative)

    by Jesus IS the Devil (317662) on Friday March 19, 2004 @04:37AM (#8607747)
    If you have RedHat and can't do the up2date any longer, here's what I did to make mine work:

    wget http://www.openssl.org/source/openssl-0.9.7d.tar.g z
    tar xvfz openssl-0.9.7d.tar.gz
    cd openssl-0.9.7d ./config shared --prefix=/usr
    make
    make test
    make install

    Configure with "shared" because it will install the shared library, which is needed for other programs such as SSHD. The prefix is where RedHat put its *.so files that's needed by OpenSSH.

    Not sure if it's required or not, but I just restarted SSHD (uses OpenSSL) after that just in case.

    Btw, the above is just what I did. I make no warranties. Follow it at your own risk. :)
  • by donheff (110809) <donheffernan@FREEBSDyahoo.com minus bsd> on Friday March 19, 2004 @07:55AM (#8608326)
    I see a fair number of posts from people who rely on /. to learn about security flaws. That doesn't seem to be a sensible approach. It is pretty easy to follow a security list and keep an eye out for vulnerabilities affecting your system(s). I am a home user with a simple Web server in the basement. I subscribe to the CERT list. Others here mentioned Bugtraq. I catch quite a few alerts that I don't hear about in more general forums until after I see activity in my Snort logs. Even with a nightly update via yum some things need individual attention. Case in point, a flaw in a PHP application (Gallery) that falls outside of the packages covered by yum. You have to know about it to fix it -- and the bad guys know about immediately.

    Don
  • by master_p (608214) on Friday March 19, 2004 @11:17AM (#8609864)

    A null-pointer assignment

    an out-of-bounds read

    Aside from the programmer's errors, if C was safer, both bugs would have already been caught a long time ago. C is clearly to blame here.

Never trust an operating system.

Working...