Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Debian GNU is Not Unix Open Source Red Hat Software Security Ubuntu Linux IT

Not Just Apple: GnuTLS Bug Means Security Flaw For Major Linux Distros 144

Posted by timothy
from the holes-to-plug dept.
According to an article at Ars Technica, a major security bug faces Linux users, akin to the one recently found in Apple's iOS (and which Apple has since fixed). Says the article:"The bug is the result of commands in a section of the GnuTLS code that verify the authenticity of TLS certificates, which are often known simply as X509 certificates. The coding error, which may have been present in the code since 2005, causes critical verification checks to be terminated, drawing ironic parallels to the extremely critical 'goto fail' flaw that for months put users of Apple's iOS and OS X operating systems at risk of surreptitious eavesdropping attacks. Apple developers have since patched the bug." And while Apple can readily fix a bug in its own software, at least for users who keep up on patches, "Linux" refers to a broad range of systems and vendors, rather than a single company, and the affected systems include some of the biggest names in the Linux world, like Red Hat, Debian, and Ubuntu.
This discussion has been archived. No new comments can be posted.

Not Just Apple: GnuTLS Bug Means Security Flaw For Major Linux Distros

Comments Filter:
  • by Anonymous Coward

    Who uses GnuTLS over OpenSSL anyway?!

    • Re: (Score:2, Troll)

      Anyone who can't get into the trap of the OpenSSL non-advertising licensing issue which is not compatible with the GPL license.
    • by MightyYar (622222)

      In my ports tree:
      audio/ario
      audio/pianobar
      deskutils/fusenshi
      deskutils/taskd
      deskutils/taskwarrior
      devel/gwenhywfar
      devel/gwenhywfar-fox16
      devel/gwenhywfar-gtk2
      devel/gwenhywfar-qt4
      devel/librelp
      devel/

      • by OneAhead (1495535)
        Not all of these will manifest the flaw in an easily (or remotely) exploitable way. Taking a very lazy glance at the list, samba, the apache module and hydra could of course be a problem, and the ones in mail/ too. Still a serious issue.
    • by Aethedor (973725)
      Not GnuTLS, but PolarSSL. Reason for moving away from OpenSSL is because of it's horrible documentation. Or, better said, the lack of any documentation. Tried to implement SNI support in my open source web server (Hiawatha http://www.hiawatha-webserver.... [hiawatha-webserver.org]), but there was no proper documentation or example code available. With PolarSSL, it was done within a day. All other SSL features were implemented in a more cleaner way. No ugly callback stuff. Even with the OpenSSL 1.0.0 release some time ago their doc
  • It's time (Score:5, Funny)

    by Ol Olsoc (1175323) on Sunday April 06, 2014 @08:29AM (#46675783)
    This if nothing else, should show everyone it's time to switch to Windows, the OS immune to exploits.
  • Old news (Score:5, Insightful)

    by David Jao (2759) <djao@dominia.org> on Sunday April 06, 2014 @08:30AM (#46675789) Homepage
    This is quite old news, why is slashdot only picking up on it now?

    The impact of this bug does not compare to the goto fail bug. Most Linux distributions use OpenSSL for TLS. Even if a program links to GnuTLS, it may not use GnuTLS for certificate validation, and if it doesn't, then it's not affected by this bug (one example is Google Chrome). It's not like iOS where everything is required (by App Store rules) to use SecureTransport.

    • Re: (Score:2, Interesting)

      by postbigbang (761081)

      It indeed is the same level as the bug Apple fixed. Plentiful access methods are hinged on this lib and code.

      It's non-trivial, and affects clients and servers in a wide breadth. Yes, were you watching, you'd have upgraded to fixed versions. Too many, however, don't know the difference between a CVE and a live hand grenade. Or they weren't watching. Same vulnerability result.

      • by rubycodez (864176)

        you are silly, it's already been patched and moreover the gnu crap isn't widely used on web connected servers.

        it's a non-issue

        • Re: (Score:3, Funny)

          by BasilBrush (643681)

          "The GNU crap". :-)

          It's amazing how quite the FOSS community will throw Stallman under the bus, if the alternative is accepting parity with Apple's security bug.

    • Near Zero Impact (Score:5, Informative)

      by marienf (140573) on Sunday April 06, 2014 @08:47AM (#46675911) Homepage

      > Most Linux distributions use OpenSSL for TLS.
      > Even if a program links to GnuTLS, it may not use GnuTLS for certificate validation,
      > and if it doesn't, then it's not affected by this bug (one example is Google Chrome)

      Agree. I've ran through everything that linked to gnutls on my distro (Arch) and although there's
      quite a lot of binaries that do, most of those do not offer TLS connections (or any network connectivity at all), so my
      guess (without knowing GNuTLS at all) is that they use some other feature offered by the library.

      Of those that I know actually capable of SSL/TLS connections, all (also) link to OpenSSL.

      So without making a definitive statement, AFAICT this should have near zero impact on GNU/Linux.

      • by Anonymous Coward

        so my guess (without knowing GNuTLS at all) is that they use some other feature offered by the library.

        Probably because just like OpenSSL it provides implementations of hash functions (MD5 SHA1 etc), private key algorithms etc
        http://gnutls.org/manual/gnutls.html#Using-GnuTLS-as-a-cryptographic-library

      • by Anonymous Coward

        Check the arch reverse dependencies - wget might be impacted. Pretty much nothing else that's popularly used is affected. As others have said, fortunately, this was patch last month.

    • Re:Old news (Score:5, Funny)

      by ganjadude (952775) on Sunday April 06, 2014 @08:47AM (#46675917) Homepage
      its a timmy post...

      "Linux" refers to a broad range of systems and vendors, rather than a single company,

      really? this is /. timmy, get with the program, everyone knows this because THIS YEAR will be the year of linux on the desktop

      • by Gunstick (312804)

        I checked. Running linux on the desktop since 16 years.
        So yeah, no news for me.

        There will be no linux on the desktop, because the desktop dissapears. But there is already linux on the smartphone, if you say it's unix on the smartphone, then there are even more... and add all tablets into the mix.

    • Re:Old news (Score:5, Informative)

      by swillden (191260) <shawn-ds@willden.org> on Sunday April 06, 2014 @08:47AM (#46675923) Homepage Journal

      This is quite old news, why is slashdot only picking up on it now?

      Slashdot picked it up on March 4th [slashdot.org], actually. This is a dupe.

      The impact of this bug does not compare to the goto fail bug.

      Agreed.

    • by Sipper (462582)

      Most Linux distributions use OpenSSL for TLS. Even if a program links to GnuTLS, it may not use GnuTLS for certificate validation, and if it doesn't, then it's not affected by this bug (one example is Google Chrome). It's not like iOS where everything is required (by App Store rules) to use SecureTransport.

      Another (non-issue) example is MTA (email) transfers; typically on Linux systems MTAs such as Exim use GnuTLS for TLS transfers, but purposely don't do certificate verification (but can be specifically configured to do so).

      This is still a serious security issue for anything that does use GnuTLS for certificate verification of course, but off the top of my head I don't have a specific example of where this is done on the Linux platform. [There probably is an example to be found somewhere though.]

    • by c4t3l (3606237)
      What is even funnier is that "one of the biggest names in the Linux world, "RedHat"" fixed the damn bug the day before the original article was published... Nice try idiots (read Ars Technica)...
    • It's not like iOS where everything is required (by App Store rules) to use SecureTransport.

      It's worth noting there is 100% no such rule. There is no app store rule enforcing any certificate validation or networking technology. Almost all the app store rules these days are around content, not technical implementations. The only technical rule I can think of off the top of my head is no using private functions in Apple's libraries, which is a no brainer.

      OpenSSL is widely used, and in fact has it's own section in Apple's documentation acknowledging so. From TFM:
      "Further, although OpenSSL is commonly

      • by David Jao (2759)
        You missed one major technical rule: all browsers on iOS that support local rendering are required to use the system rendering engine.
        • You missed one major technical rule: all browsers on iOS that support local rendering are required to use the system rendering engine.

          Yeah. To Google and Mozilla, this is probably a big deal. To a developer? As long as the content runs, it doesn't really matter. I've never really found an instance where I'm going "Gee, I really wish I was able to embed Chrome here."

          It is a little frustrating UIWebView on iOS doesn't have all the DOM editing/inspection functions that WebKit on the desktop has, but it is pretty flexible and customizable. In relation to the original article, you can even override the connection functionality and probably ove

        • by dgatwood (11270)

          You missed one major technical rule: all browsers on iOS that support local rendering are required to use the system rendering engine.

          Actually, no, I'm pretty sure they're just not allowed to use any JavaScript engine other than the built-in JavaScriptCore. And as of iOS 7, it's theoretically possible to actually do so without using WebKit.

    • by hydrofix (1253498)

      This is quite old news, why is slashdot only picking up on it now?

      Slashdot did pick it up [slashdot.org] earlier already when it was first announced. So it's a dupe, really.

    • by neiras (723124)

      This is a dupe. We saw this on slashdot weeks ago.

    • The GnuTLS bug is freakishly easy to exploit. The OpenSSL bug at least requires you to modify your code to exploit the bug. This one is almost work-free.

      If the same bug appears on OpenSSL, I would immediately disable all SSL related applications.

      Thank god nothing uses GnuTLS...except aptitude.

      (I am a security researcher who spent a day or 2 researching these 2 bugs)

  • by Zontar The Mindless (9002) <plasticfish.info ... m minus language> on Sunday April 06, 2014 @08:31AM (#46675803)

    My distro patched this over a month ago.

    • by thoth (7907)

      Slow weekend at Ars? Had you actually looked at the Ars article, you may have noticed it was from one month ago, March 4 2014.

      The fact it's here now (and is also a dupe of a previous article here) reflects more on Slashdot and its submitters and editors, than Ars.

      • Had you actually read this thread, you'd have seen that the article date has already been brought up, and I've already taken note of same. But, hey, thanks for playing.

  • There are rumours... (Score:4, Interesting)

    by gnasher719 (869701) on Sunday April 06, 2014 @08:32AM (#46675809)
    that Apple took notice of some accusations that the NSA managed to modiy some open source codebases, reviewed all code that was checked in at about the suspicious time frame, and found the "goto fail" bug that way. No idea whether this is true, but I'd be curious who checked in this bug.
  • People use GnuTLS? (Score:4, Insightful)

    by aleph (14733) on Sunday April 06, 2014 @08:39AM (#46675845)

    Is anyone other than Debian zealous enough to use GnuTLS?

    I rarely agree with Howard Chu of OpenLDAP fame, but... http://www.openldap.org/lists/... [openldap.org]

    • by neiras (723124)

      Hey! I got the karma for posting that link in the first article, you... you... karma whore! ;)

  • by Anonymous Coward

    And use OpenSSL. As awkward as it may be, it doesn't have the design flaws that GNU TLS does.

    • You should poke through the OpenSSL code some day. It's pretty stinky.

  • by Anonymous Coward on Sunday April 06, 2014 @08:49AM (#46675935)

    Are you trolling for an Apple-vs-Linux flame war? do you have a zealous attachment to Apple? or are you just dull?

    1) This is old news, and the /. has already reported on it;

    2) Hardly anything uses the GNU TLS library, and for the same reason people have been advising against Apple's rewrite of security libraries: because it's better to use something that's had over a decade of development and review and is widely deployed across a series of platforms;

    3) You're arguing about the heterogeneity of the Linux platform as if it's a bad thing, while in fact this acts in Linux's favour. Even though the GNU project might like people to use gnutls, distros have chosen not to. Apple either discourages choice or makes it impossible, depending on what exactly you're targeting, which is why everything was affected.

    • by sirlark (1676276)
      And what's this saying that heterogeneity of the Linux world will make fixing it more difficult? Fix it upstream, and most distros, and ALL the major ones will have it out a s a security update in less than a week.
  • Fixed at the beginning of March.
    Example: http://advisories.mageia.org/MGASA-2014-0117.html

    "Nothing to see here. Move on."

  • Create a library with that name that does nothing, or logs errors for any entry points. Why is something being shipped that is insecure. I understand that the builds have to be changed. But the library could be replaced with a skeleton right now, can't it?
    And maybe we would see that its not quite as in-active as people think.

    • by Sipper (462582) on Sunday April 06, 2014 @09:09AM (#46676079)

      Create a library with that name that does nothing, or logs errors for any entry points. Why is something being shipped that is insecure. I understand that the builds have to be changed. But the library could be replaced with a skeleton right now, can't it?
      And maybe we would see that its not quite as in-active as people think.

      There are two distinct part of SSL/TLS; encryption and authentication. In this case it's only the authentication portion that has an issue, not the encryption portion. There are several places in which GnuTLS is used for encryption but not authentication such as MTA (email) transfers over TLS (at least most of the time).

      As for why GnuTLS exists, AFAIK it's mainly because of licensing issues -- compiling a GPLv2+ program against OpenSSL gets into licensing troubles, so there needed to be a GPL compatible alternative.

      • by swillden (191260)

        There are two distinct part of SSL/TLS; encryption and authentication. In this case it's only the authentication portion that has an issue, not the encryption portion.

        Unauthenticated public key encryption is useless against an active attacker (one able to modify traffic, rather than just eavesdrop on it).

        There are several places in which GnuTLS is used for encryption but not authentication such as MTA (email) transfers over TLS (at least most of the time).

        Huh? Even for SSMTP, certificates can -- and must! -- be checked.

        • by Sipper (462582)

          There are several places in which GnuTLS is used for encryption but not authentication such as MTA (email) transfers over TLS (at least most of the time).

          Huh? Even for SSMTP, certificates can -- and must! -- be checked.

          I think you mean ESMTPS. And no, usually TLS certificates are not checked by default (they can be, optionally); many TLS certificates used for ESMTPS are not signed by a CA, so there's nothing to check them against. There's also a new DANE protocol where domains that are using DNSSEC can specify TLS certificate details for mail in the DNS record for the domain, but this is currently not popular (supposedly only about 20 domains are using it). Other issues with this are that a number of DNS servers haven'

          • by swillden (191260)

            It's better to at least have encrypted email transfers than to only allow encrypted transfers from authenticated senders.

            Better in what sense? Without authentication MITM attacks are trivial, making the encryption irrelevant.

            If what you say is true (and it probably is) then the state of e-mail security is even worse than I thought it was. Most mail providers don't support TLS anyway, but without authentication it doesn't really matter if they do.

            • by Xylantiel (177496)
              MITM requires active interception to eavsdrop, wheras an unencrypted connection is vulnerable to passive eavesdropping. That is the sense in which an encrypted but not properly authenticated connection is "better". Also if the ID of the offered certificate is logged it is possible to audit for a MITM attack after the fact. According to Snowden, the NSA can crack 1024 bit certs' private keys. So really even properly verifying the cert is not secure depending on who your adversary is.
              • by dkf (304284)

                MITM requires active interception to eavsdrop

                It's not like it's impossible to have toolkits for making active interception nearly trivial to do (provided you've got the hardware to run it on) and if you're thinking about ISPs or governments as the attackers, they've got access to the sorts of hardware which can run active interception on a massive scale.

                Your main defence against them is that your life is very boring and ordinary and they don't give a shit about you. It's the other major group of attackers — plain old criminals who want to steal

              • by swillden (191260)

                MITM requires active interception to eavsdrop, wheras an unencrypted connection is vulnerable to passive eavesdropping.

                Yes, of course. However, in practice the set of real-world circumstances in which an attacker manages to get sufficient physical access to eavesdrop without also getting sufficient physical access to perform active attacks are vanishingly small, at least in the wired networking space. For wireless it's different, of course (assuming there's no link-layer encryption applied), but inter-MTA transfers are almost never wireless.

            • by Sipper (462582)

              If what you say is true (and it probably is) then the state of e-mail security is even worse than I thought it was. Most mail providers don't support TLS anyway, but without authentication it doesn't really matter if they do.

              Actually it's quite common for email providers to support TLS transfers today. And the reason I think that's true is that one isn't required to purchase a CA-signed certificate to get that working. If we all had to purchase a CA-signed certificate, I think it would become more rare to see TLS transfers to/from privately-held servers.

              If you look at the mail headers for email you receive, you're likely to find "smtps" or "esmtps" in the Received: lines which indicates that it was sent via a TLS transfer. M

              • by swillden (191260)

                And the reason I think that's true is that one isn't required to purchase a CA-signed certificate to get that working. If we all had to purchase a CA-signed certificate, I think it would become more rare to see TLS transfers to/from privately-held servers.

                I think you're arguing that would be a bad thing, but in reality it'd be a nearly-irrelevant thing. Without authentication, encryption protects only against the most casual of snoopers, most of whom wouldn't be able to sniff the packets anyway.

                • by Sipper (462582)

                  And the reason I think that's true is that one isn't required to purchase a CA-signed certificate to get that working. If we all had to purchase a CA-signed certificate, I think it would become more rare to see TLS transfers to/from privately-held servers.

                  I think you're arguing that would be a bad thing, but in reality it'd be a nearly-irrelevant thing.

                  No. The word "reality" doesn't apply here, because what you're describing isn't what's being actually done for SMTP.

                  Without authentication, encryption protects only against the most casual of snoopers, most of whom wouldn't be able to sniff the packets anyway.

                  No, but I understand why you'd think this, as it seems to be a common misconception. If you have a specific example to illustrate this case, that would help.

                  • by swillden (191260)

                    No, but I understand why you'd think this, as it seems to be a common misconception. If you have a specific example to illustrate this case, that would help.

                    MITM attack.

                    • by Sipper (462582)

                      No, but I understand why you'd think this, as it seems to be a common misconception. If you have a specific example to illustrate this case, that would help.

                      MITM attack.

                      That's not a specific example related to TLS or encryption, it's a vague attack classification. The reason I'm asking the question is to find out if there is an actual issue, and so a vague answer like this cannot help our understanding any.

                      Oh well. OpenSSL apparently has a vulnerability too. sigh :-/

                    • by swillden (191260)
                      I feel like I'm spelling out the obvious, but: mail server A opens a TLS connection to mail server B to transfer mail, which starts with a TLS handshake, requiring B to send its public key A. The attacker intercepts the message and sends his public key to A, and completes the handshake with both sides, then proceeds to happily pass the data through reading all of it, since he has the session keys on both sides.
                    • by Sipper (462582)

                      I feel like I'm spelling out the obvious, but: mail server A opens a TLS connection to mail server B to transfer mail, which starts with a TLS handshake, requiring B to send its public key A. The attacker intercepts the message and sends his public key to A, and completes the handshake with both sides, then proceeds to happily pass the data through reading all of it, since he has the session keys on both sides.

                      You've skipped over the PFS key exchange portion used in TLS.

                      https://en.wikipedia.org/wiki/... [wikipedia.org]
                      https://en.wikipedia.org/wiki/... [wikipedia.org]
                      https://en.wikipedia.org/wiki/... [wikipedia.org]

                      Maybe the MITM exploit you're talking about is possible, I don't know.

                    • by swillden (191260)
                      It is. There are many tools out there that implement it. It's the whole reason that we use CAs -- not that they're an ideal solution to the problem, but without some way to verify the authenticity of the public key you're using to bootstrap the key exchange, any PK-based key agreement protocol is subject to MITM attacks.
                    • by Sipper (462582)

                      It is. There are many tools out there that implement it. It's the whole reason that we use CAs -- not that they're an ideal solution to the problem, but without some way to verify the authenticity of the public key you're using to bootstrap the key exchange, any PK-based key agreement protocol is subject to MITM attacks.

                      MITM can be an issue. More detailed information about the state of things at the link below.

                      https://wiki.exim.org/lurker/m... [exim.org]

      • Yes its used, but only sometimes. Only for that mail stuff, and hey maybe only if someone else is handling authentication because we know thats broken. And we need the stuff there for legal reasons and we need it there as an alternative. Just in case we need to use it, even though we know its broken.

        So tell me, why cant we have the parts we know are insecure issue a log each time they are run?

        • libgnutls26:amd64 2.12.23-1ubuntu4.2

          zless /usr/share/doc/libgnutls26/changelog.Debian.gz

          gnutls26 (2.12.23-1ubuntu4.2) saucy-security; urgency=medium

          * SECURITY UPDATE: certificate validation bypass
          - debian/patches/CVE-2014-0092.patch: correct return codes in
          lib/x509/verify.c.
          - CVE-2014-0092

          -- Marc Deslauriers Mon, 03 Mar 2014 14:14:00 -0500

        • by Sipper (462582)

          So tell me, why cant we have the parts we know are insecure issue a log each time they are run?

          I understand what you're trying to get at; you'd like to have a log of the failure. However unfortunately that wouldn't tell you what you needed to know in this case; if you did have logging on this, the result you'd get would be "client authenticated" even though it was possible that the authentication actually didn't succeed. :-(

          The unfortunate truth is that software bugs happen, and bugs that report success are harder to find than bugs that cause a failure.

  • "Linux" refers to a broad range of systems and vendors

    Actually, Linux refers to the operating system kernel which has nothing to do with GnuTLS. (Wow, someone actually uses GnuTLS?)

    • by Bengie (1121981)
      "Linux" refers to whatever people want it to refer to. Language is decided by the majority and you're the minority, meaning you're using it incorrectly.
  • From the Really Bad Submission:

    And while Apple can readily fix a bug in its own software, at least for users who keep up on patches, "Linux" refers to a broad range of systems and vendors, rather than a single company, and the affected systems include some of the biggest names in the Linux world, like Red Hat, Debian, and Ubuntu.

    Gee. it sure is a problem that Red Hat, Debian, or Ubuntu couldn't just, you know, fix the bug and recompile the source code. Oh wait, they already did

    FTFA

    GnuTLS developers published this bare-bones advisory that urges all users to upgrade to version 3.2.12. The flaw, formally indexed as CVE-2014-0092, is described by a GnuTLS developer as "an important (and at the same time embarrassing) bug discovered during an audit for Red Hat." Debian's advisory is here.

    • by exomondo (1725132)

      Gee. it sure is a problem that Red Hat, Debian, or Ubuntu couldn't just, you know, fix the bug and recompile the source code. Oh wait, they already did

      I think the point TFS is trying to make is that GnuTLS maintainers can't just fix the issue and push the fix to end users, it has to go through the vendors first. The same PITA issue that Android users have with OS updates having to go through carriers where sure the tech-savvy minority that happen to know about it can chase down the fix, recompile and re-install their systems but the vast majority of people can't and so are exposed to vulnerabilities for a much longer time.

  • And while Apple can readily fix a bug in its own software, at least for users who keep up on patches, "Linux" refers to a broad range of systems and vendors, rather than a single company, and the affected systems include some of the biggest names in the Linux world, like Red Hat, Debian, and Ubuntu.

    Now, who was this comment for? Half the stories generate complaints about obcure acronyms and lack of context in the summary, but you manage to throw that in?

  • And while Apple can readily fix a bug in its own software, at least for users who keep up on patches, "Linux" refers to a broad range of systems and vendors, rather than a single company, and the affected systems include some of the biggest names in the Linux world, like Red Hat, Debian, and Ubuntu.

    And thanks to the LGPL license of GnuTLS, all the users have the possibility to upgrade their systems, independently of whether Red Hat, Debian, Ubuntu, Apple, Microsoft believe that maintaining those systems is still commercially convenient or not. GPLv3 would be better, as it would give the users the warranty of being able to actually install the updated code into their devices, which is important for non-PCs.

  • Looks like someone can't tell the difference between "March" and "April". Hint: "April" is the one that starts with an "A".

    The major distros posted patches for this flaw to their repositories within a day or two of it being made public. (Not to say that it isn't embarrassing for stuff like this to make it into the codebase; but at least it was fixed quickly once it was discovered.)

  • Microsoft PR Fail (Score:4, Interesting)

    by darkonc (47285) <stephen_samuel.bcgreen@com> on Sunday April 06, 2014 @03:10PM (#46678471) Homepage Journal
    I don't mind the heads-up about a little-used piece of Gnu software (as pointed out, most distros push OpenSSL), but I do mind astro-turfing the Microsoft PR line of "Nobody's responsible if Linux fails!"

    The irony, of course, is that most people haven't read Microsoft's EULA which effectively says 'Not only are we not responsible if Windows fails, but we'll sue you if you try to fix it yourself.'

    This is really gonna bite the hundreds of millions running XP who will be orphaned this year when Microsoft stops supporting it. Not only do they face the prospect, in a matter of weeks, of never again seeing security updates from Microsoft, but it will be illegal to even try to fix future bugs themselves (or hire a third party to do it).

    This last bit is something that Linux users have as a right

  • Oracle installs the Ask toolbar!!!!!!!!!!!!!!

  • The ones that were fixed by the updates for all RHEL-derived distros, like CentOS, a month ago?

                      mark

  • Wow who submitted this? This is over a month old and was already on slashdot when it was breaking. Everyone should be patched by now.

"Lead us in a few words of silent prayer." -- Bill Peterson, former Houston Oiler football coach

Working...