Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Security

Microsoft, zlib, and Security Flaws 497

nakhla writes: "News.com is reporting that Microsoft's use of code from the open-source zlib library has led to possible security problems. The flaws in zlib were reported recently, and apply to several key Microsoft technologies, such as DirectX, Front Page, Install Shield, Office, and Internet Explorer. The article also mentions how this is not Microsoft's first use of open-source code in its software, but does point out that since zlib is not GPL'd they are under no obligation to release the source code to any of their products."
This discussion has been archived. No new comments can be posted.

Microsoft, zlib, and Security Flaws

Comments Filter:
  • by Nonesuch ( 90847 ) on Thursday March 14, 2002 @04:50PM (#3164673) Homepage Journal
    Any bets on how long before Microsoft issues a press release noting that this is yet another risk of using evil open source and open standards?
    • by Mr Windows ( 91218 ) on Thursday March 14, 2002 @04:55PM (#3164720)
      ISTR that MS are nominally in favour of open source, as long as it's not that nasty cancerous GPL open source. Now we see why: if they can use others' work without having to reciprocate, it makes life better for them (in the short term, that it).

      Of course, if zlib had been GPL, they couldn't (legally...) have used it without releasing their source, and in this case, they might have avoided the security risks: either non-use of zlib (not affected by this vulnerability) or use of zlib + release of code (easy and quick for anyone to release a patch, instead of having to wait for the "official" version with all it's "added extras").

      • "if" M$ does use GPLed source, somewhere down the line it will come out.

        Case in point. A GPLed piece of software has bug X, and strangly enough, a M$ product has the same bug.

        It maybe worth the time to test major bugs in GPLed software against M$ programs if such simularities do exist.

        Just a thought.
  • Tally anybody? (Score:2, Offtopic)

    by ILikeRed ( 141848 )
    I wonder if anyone is keeping a running tally since the security initiative started???

    Here is another bug [appsecinc.com] with the MicroSoft SQL server. They've got overflows in their stored procedures. No fix, but you can delete the files if you can live without them....
  • GZIP Patch (Score:4, Informative)

    by Embedded Geek ( 532893 ) on Thursday March 14, 2002 @04:54PM (#3164713) Homepage
    The patch can be found at http://www.gzip.org/#patch [gzip.org]. It turns out that passing a filename over 1200 characters would cause an overflow.

    For the record, I've used GZLIB in many embedded products and like it.

    • by Embedded Geek ( 532893 ) on Thursday March 14, 2002 @04:58PM (#3164751) Homepage
      It's actually 1020, not 1200 chars. The entire statement is here:

      i>gzip 1.2.4 may crash when an input file name is too long (over 1020 characters). The buffer overflow may be exploited if gzip is run by a server such as an ftp server. Some ftp servers allow compression and decompression on the fly and are thus vulnerable. See technical details here [securityfocus.com]. This patch [slashdot.org] to gzip 1.2.4 fixes the problem. The beta version 1.3.3 [gnu.org] already includes a sufficient patch; use this version if you have to handle files larger than 2 GB. A new official version of gzip will be released soon.

  • by dhopton ( 252883 ) on Thursday March 14, 2002 @04:55PM (#3164722)
    As the subect. InstallShield Corp. Make install shield.
  • ...if the government hadn't worked so hard to limit Microsoft's ability to innovate.

    :P
  • InstallShield (Score:5, Informative)

    by sharkey ( 16670 ) on Thursday March 14, 2002 @04:57PM (#3164735)
    InstallShield is written and published by a company named InstallShield, and has been for many years. It is not a "Microsoft technology", but rather a technology that has support for creating software installation routines for Windows, amongst other OSes.
    • InstallShield is now a GUI for the Microsoft Installer, which is most certainly a Microsoft product.

      Using Microsoft Installer is a requirement to get the official "designed for Microsoft Windows 2000" sticker on your product, and I assume its the same for XP. Wise also has a front end to the Installer system, IIRC and FWIW.
    • by ChrisDolan ( 24101 ) <chris+slashdot@@@chrisdolan...net> on Thursday March 14, 2002 @05:50PM (#3165124) Homepage
      Similarly, IE is not written by Microsoft either. It's alien technology. It was discovered by a MS coder who stumbled on a crashed spacecraft while hiking in the woods in the mid-90s. Using him as a vessel, the program infected the Windows codebase and has grown since then, digging it's tendrils deeper and deeper into the system.

      So when MS says they can't remove IE from Windows, it's true.
  • notification issue (Score:5, Insightful)

    by ethereal ( 13958 ) on Thursday March 14, 2002 @04:58PM (#3164744) Journal

    Here's what I want to know: the zlib maintainers know that their code is heavily used in open source product, and they can easily use ldd on a typical Linux or *BSD install to find out exactly which programs use zlib. So they know who to contact about vulnerabilities. However, if Microsoft just takes open source code and incorporates it into their products, how will the zlib folks know to contact them prior to public disclosure? It surely can't be the responsibility of the zlib team to grep through every single closed-source binary out there in order to make sure that it didn't use zlib.

    It seems like if there isn't a mailing list for every single library's security issues, then closed source vendors will become second-class citizens when it comes to getting forewarning about a big security announcement like this. This seems like what has happened to Microsoft in this case; otherwise they would have had a raft of fixes available when the original story was released, right?

    The other alternative is the vendor early warning list idea that Microsoft has been pushing, but the problem with that is: the more people on the list (and you'd have to have hundreds of vendors in the case of a base library like zlib, I'd think), the more likely that one of them will leak the story to the black hats, so that the delay while vendors prepare patches becomes a liability for the unpatched public. That doesn't seem like a good scenario to me either.

    • by garett_spencley ( 193892 ) on Thursday March 14, 2002 @05:11PM (#3164850) Journal
      I don't see it as the zlib author's responsibility to notify everyone that uses their library.

      I do feel that they should (but are not obligated to) send out a few public notices that will be spread around so that people who's programs use the library can update it and that's exactly what they did.

      Also the big problem with this security issue isn't programs that dynamically link to libz.so. Those are easy to fix because all you have to do is upgrade your zlib and they're automagically fixed.

      It's the programs that statically link the zlib library (meaning it gets copied right into the actual binary at compile time) that you have to worry about because an ldd won't show you that.

      Also many people use their own modified version of zlib (XFree86, rpm, rsync, the linux kernel etc.) and so those are very hard to catch as well.

      Florian Weimer wrote a perl script which will check for binaries on your system that are statically linked. You can read his post to Bugtraq here [securityfocus.com].

      --
      Garett
      • by csbruce ( 39509 )
        I do feel that they should (but are not obligated to) send out a few public notices that will be spread around so that people who's programs use the library can update it and that's exactly what they did.

        Unless I am missing my guess, I ran into this particular bug in zlib about a year ago and I e-mailed the people at the project address. They responded that they already knew about it and sent me the patch. So what exactly is it that happened recently? Did someone figure out a way to use the bug to crack a system and this set off all kinds of alarms? There should have been a zlib fix-up release a long time ago.
  • Debian? (Score:2, Interesting)

    by DRO0 ( 252117 )
    Naive question probably, but if zlib isn't GPL then does Debian use a different library and if so, is it affected by this issue?
  • by borgquite ( 197429 ) <minkus&ntlworld,com> on Thursday March 14, 2002 @05:02PM (#3164780) Homepage
    is if when they released the patch for the security flaw they made the patch GPL... just imagine Microsoft having to recode all that stuff for themselves :)
  • hrm... (Score:2, Informative)

    by Em Emalb ( 452530 )
    "The zlib library has been a fundamental open-source software component for almost a decade and can be found in almost every Linux and Unix system. That means the so-called "double free" flaw in the library may leave a hefty portion of Linux and Unix systems open to attack. Because it adopted some of the code, Microsoft apparently has made itself vulnerable to the flaw as well. "

    Disclaimer: I am not a security weenie, so I don't know this for fact......*deep breath*....

    If this is true, why is it only news for MS? It appears that Linux and Unix is also vulnerable. So why only set up the article as MS related?

    *bash MS* bash bash bash....it's popular right?
    • Re:hrm... (Score:5, Interesting)

      by IO ERROR ( 128968 ) <errorNO@SPAMioerror.us> on Thursday March 14, 2002 @05:07PM (#3164821) Homepage Journal
      If this is true, why is it only news for MS? It appears that Linux and Unix is also vulnerable. So why only set up the article as MS related?


      Because we found out for Linux/Unix several days ago and got our systems fixed within 24 hours. Microsoft is still trying to figure out what the hell is going on.


      *bash MS* bash bash bash....it's popular right?


      It's popular, easy, and well-deserved in this case. So much for M$ paying attention to security. Someone in M$ should have known they used zlib code, exactly where it was, and gotten patches out in a reasonable timeframe. They didn't. Bash bash bash.

      • It was well known at the time the Linux article came out that Microsoft also had zlib code in their software.

        I mean... DUH... IIS and IE support the Content-Encoding extensions from HTTP 1.1 that use gzip for compression and the easiest way for them to have implemented that was functions from zlib.

        Now what I want to know is how you have come to the conclusion that Microsoft uses the code in the specific way necessary to exploit it. Or if they even use that particular function, or if they haven't already fixed it long ago in their source tree.

        Speculation and wild claims don't add any value, and that's what this article does and what your post does. Yes, it is popular to bash MS.

        Now let's get to the real question. How come this bug got into zlib in the first place?
      • They're not dealing with a fairly small number of reasonably savvy users who go to read slashdot, discover that zlib has a bug and decide to go fix their systems. MS deals with millions upon millions of 'ordinary users' who run dozens of programs that have zlib linked statically (we've just been told) and who have absolutely no idea what zlib is, what their systems use it for or how to patch it (well, they can't, because it's statically linked). So it makes sense for MS to determine first which apps are affected, in what way (is DirectX ever going to run into this problem? if yes, what are the consequences? if no, or if the consequences aren't serious enough, getting millions upon millions of clueless users to download a DirectX patch ASAP isn't worth the trouble). I agree with you that they should have information handy on which of their apps link to zlib, but who's to say they don't and they're just taking this time to conduct a risk inventory (they're a big ass bureaucratic monstrosity after all)?
    • It was news for Linux/UNIX earlier this week [slashdot.org] idiot. Go crawl back under your Microsoft apologist rock please.
    • Re:hrm... (Score:2, Interesting)

      by brettb ( 64079 )
      Of course some ./er's will take the opportunity to bash Microsoft but the article itself isn't.
      The zlib library vulernabilty and how *nix based systems are affected has [slashdot.org]
      already been discussed on slashdot.

      This Cnet article references the previous Cnet article [com.com] on the subject which speculated that since zlib is a programming library that could be used across platforms that other OS's application programs may be affected as well.

      I don't see this article as Microsoft bashing. It just adds a new slant to the previous article and confirms that *nix systems aren't the only ones affected.

      This is important information for those Microsoft admins out there who may not care about last weeks headline "Flaw Leaves Linux Computers Vulnerable". Maybe now they'll be keeping their eyes open for patches of their affected software

      .
    • Consider this: it appears that M$ will have to release a fixpak/security pak for a bunch of apps while for me with linux (and people using BSD, etc) all we need to do is install the new zlib - which was available virtually at the same time the POTENTIAL vulnerability was discovered/released. Then, all *nix people need do is restart whatever net-connected app/server they were running that uses zlib and it is fixed. No replacing apps with fixed apps, just replace the lib without ever rebooting.


      You will eventually receive a big security fix from M$ that replaces whole applications AND have to reboot to make it work.


      So, two comparisons can be made between the free-os users and the M$ slaves: 1) fixes are produced and available immediately for free-os people but it will be a while before M$ figures out what to do, and 2) simply installing the new lib and, perhaps, restarting a couple applications is all it takes for a fix for the free-oses but M$ users will have to replace whole applications and reboot.


      M$ kinda trashes itself in comparison.

  • http://www.gzip.org/zlib/apps.html

    At least nine of Microsoft's major applications--including Microsoft Office, Internet Explorer, DirectX, Messenger and Front Page--appear to incorporate borrowed code from the compression library and could be vulnerable to a similar attack.

    "Borrowed"? Whats the license for zlib?

    • From zlib-1.1.3:

      Copyright notice:

      (C) 1995-1998 Jean-loup Gailly and Mark Adler

      This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software.

      Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions:

      1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required.
      2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software.
      3. This notice may not be removed or altered from any source distribution.
      Jean-loup Gailly Mark Adler
      jloup@gzip.org madler@alumni.caltech.edu

      If you use the zlib library in a product, we would appreciate *not* receiving lengthy legal documents to sign. The sources are provided for free but without warranty of any kind. The library has been entirely written by Jean-loup Gailly and Mark Adler; it does not include third-party code.

      If you redistribute modified sources, we would appreciate that you include in the file ChangeLog history information documenting your changes.

  • The next-generation Graphics Device Interface is part of Windows XP, meaning that the operating system itself could be at risk.
    the colors were just screaming security flaw already weren't they?

    Yet, the incident seemingly proves that Microsoft, despite dismissing open-source code publicly, has used software from others to create their own products.
    And now they are forced to admit what we already knew, they haven't written anything original since...well...ever! :P

    The zlib compression library doesn't use the GPL, however.
    and the war between MS and GPL coninues, maybe the linux community could use Anime-based uniforms to storm microsoft and take the code back.

  • Microsoft is an old hand at using public domain stuff! They don't dislike it... like all companies they grew used to swallowing it up! It's even cheaper than buying QDOS was.

    No, the GPL is not about giving software away, that was already happening. It was about KEEPING software GIVEN AWAY.
  • by SlashChick ( 544252 ) <erica@e[ ]a.biz ['ric' in gap]> on Thursday March 14, 2002 @05:16PM (#3164890) Homepage Journal
    ...that Microsoft uses free software, I invite you to take a look at this.

    In Windows 2000, open a command prompt window. Type "nslookup". This will drop you into interactive mode for nslookup, which has been ported from UNIX (most likely BSD.)

    Now type "help". Check out this line at the bottom of the output:

    view FILE - sort an 'ls' output file and view it with pg

    Uh, yeah. Oops.
  • by Cally ( 10873 ) on Thursday March 14, 2002 @05:18PM (#3164909) Homepage

    Evidence uncovered last summer points to the Windows operating system borrowing some networking utilities and possibly parts of the TCP/IP stack, the core software that allows networking and Internet connectivity, from the open-source Unix variant FreeBSD.

    Theo de Raadt, a founder and project leader for another open-source Unix variant, OpenBSD, stressed that no conclusive proof exists, however. "I have asked repeatedly and never gotten proof," he said.


    Well it's easy to show that they use /some/ BSD
    code, at least. This is Cygwin / bash on NT4:


    andrew@INEGO(22:18:47)
    [path...] /WINNT/system32 $ grep -i regent *.EXE
    Binary file FINGER.EXE matches
    Binary file FTP.EXE matches
    Binary file RCP.EXE matches
    Binary file RSH.EXE matches

    • [path...] /WINNT/system32 $ grep -i regent *.EXE
      Binary file FINGER.EXE matches
      Binary file FTP.EXE matches
      Binary file RCP.EXE matches
      Binary file RSH.EXE matches


      That proves nothing. What if there are simple easter eggs in these binaries where that noted Microsoft developer and rock star, Ted Regent, snuck his name into the code?

    • My machine has a bunch of stuff on it so a virgin
      Win2K system MIGHT have different results but I
      handchecked that the file's date matched the
      install date on the machine. So CAVEAT EMPTOR...
      a slightly fancier grep and some patience ...

      find . -type f | while read f
      do
      strings "$f" | grep -i "Copyright " | grep -v Microsoft
      test $? -eq 0 && echo $f
      done

      showed up Thomas Lane's open source JPEG work in multiple places, Mark H. Colburn's work in system32/pax.exe, Mark Adler's PNG work in at least system32/pngfilt.dll and a few more interesting cases.

      system32/offfilt.dll has Mark Adler's inflate in it.

      c:\Program Files\Common Files\Microsoft Shared\VGX appears to have zlib based upon this:

      $ strings Program\ Files/Common\ Files/Microsoft\ Shared/VGX/vgx.dll | grep -i Copy
      4,f deflate 1.1.3 Copyright 1995-1998 Jean-loup Gailly
      f,f inflate 1.1.3 Copyright 1995-1998 Mark Adler

      And Adobe Acrobat PDFWriter also uses zlib per system32/spool/drivers/w32x86/2/pdfdd.dll.

      This is far from exhaustive of 100% scientfic but a good starting point.

      --joel
  • The next-generation Graphics Device Interface is part of Windows XP, meaning that the operating system itself could be at risk.

    Am I right in assuming this won't effect NT4 and is a direct outcome of putting the GDI back in the kernel unlike in the true microkernel architecture like HURD?

    • Re:mutatis mutandis (Score:2, Informative)

      by afidel ( 530433 )
      Well you seem to be implying that NT4 does not put the graphics code in the kernal, this is incorrect. This was one of the biggest "improvements" from nt 3.51 -> nt 4.0 is that the graphics subsystem got moved into the kernal for a speed increase. It is also (when coupled with crappy drivers) the second leading cause of nt instability after IIS =)
      • Thnx I thought the change happened with NT5 akaa Windows 2000, my mistake, sorry :) So David Cutler's original 3.1 design was fundamentally changed with the intro of NT4... I guess that would explain the new version number.
  • change it (Score:3, Insightful)

    by geekoid ( 135745 ) <dadinportland@y[ ]o.com ['aho' in gap]> on Thursday March 14, 2002 @05:24PM (#3164964) Homepage Journal
    MS want to bve able to change there EULA after you've bought the product, I'd love to see the zlib people GPL theres, then sue MS when they don't comply.
    This would force MS eithe to pay up, or go to court and fight against the very thing they want.

  • by 4of12 ( 97621 ) on Thursday March 14, 2002 @05:29PM (#3164988) Homepage Journal

    One of the other interesting things about the GPL is the side effect it has of self promotion.

    That is, I've gotten stuff from vendors using GPL software and you can tell, because their distributions contain a little src subdirectory with the GPL'd code in it.

    With the other open software licenses, there's not such a legal provision enforcing source distribution, and, hence, no advertising that the particular piece of software was used in the product.

    I bemoan the fact that much good public software and authors have not received their due credit because companies (in this particular instance, MS) have been able to incorporate their good work and not only not given them any money, but no widespread recognition of their contribution.

  • by sdowney ( 447548 ) on Thursday March 14, 2002 @05:30PM (#3165002)
    Linux's glibc has problems with double free's, that is calling free(3) on the same ptr twice causes arena corruption. As I recall, this isn't an issue for Microsoft's C library, msvcrt, so this may not be an issue for MS. If anyone is surprised that they're using zlib, don't be. Zlib's license encourages commercial adoption. This is a good thing, because it encourages wider adoption of the compression technique, and makes sure that compatibility is maintained. TCP/IP became widespread for the same reason. The BSD implementation was freely available for other Unix vendors to incorporate in their products.
    • The second free might not crash, but often some part of the code assummed the structure was still allocated after the first free and wrote to it (I'm not sure about the zlib bug). This could be very harmful if that memory had been reallocated for something else. Depending on the malloc implementation if the memory was reused for another allocation the second free() might work anyway and screw up that other allocation.

      Thus making the second free not crash may be worse than doing nothing.

      Guaranteeing that the free *does* crash may be a good idea. Supposedly then the bug will be noticed. But this may be defeated if the memory is reallocated. Also if the code goes into service without the bug being noticed, you have a definatel DOS exploit, while otherwise you may have had an unexpliotable security bug.

      Face it, there is no silver bullet.

    • A few years ago, when I was following Microsoft Windows programming issues more closely, there were several (!) vendors selling alternative malloc()/free() implementations because the Microsoft one only offered poor performance. So it's not clear at all whether Microsoft Windows programs are vulnerable or not.
  • I bet some is in there! I just bet! For god's sake, someone less lazy... um I mean less busy, than me, find GPLed code in Microsoft. I want RMS to make us all call XP GNU/XP.
  • From the advisory [gzip.org]

    There have been no reports of any exploitations of this problem, but the vulnerability exists nevertheless.

    I know most people here know this, but for some reason this bug has gotten an almost hysterical spin in the media. This is an example of the community responding to a potential risk, before any damage is done.

    All these articles that rave about millions of systems being vulnerable seem to forget the fact that nobody has been affected.

    • All these articles that rave about millions of systems being vulnerable seem to forget the fact that nobody has been affected.

      and you think this is bad? Why?

      If all the vulnerable machines get patched before anyone's affected, I'd think the system worked just as it should. I"d rather not wait until there's some nasty reprise of Nimda before starting to patch my systems.

      • It's not bad that they publicize the vulnerability, but it's bad to make it into a bigger issue than it really is. It means that when a more serious security risk comes along nobody will pay attention.

        What are you going to do in response to the next Code-Red? Declare a state of emergancy and call out the army?

        • Someone's already found a way to exploit this over ssh. There's hints (I stopped reading the thread to see if they finished it) of it working for ftp. The code with the problem is used in a huge number of places in multiple OS's.

          How big does it have to get before we acknowledge that it's a serious risk and start the patch run? I've been following the security lists about this, and I don't think the coverage is overdone at all.

  • This just points out the difference between proprietary code and open code. Those using open code incorporating this flaw have had a fix available for days (if they choose to patch and compile the source). Those using proprietary code incorporating this flaw will have to wait for the vendor to release a fix, if ever.

    If that's not a good arguement against depending on proprietary code (as for running a business), try this: If the flaw was not in open code incorporated into the proprietary code, but rather existed exclusively in the proprietary code alone (yeah, right -- proprietary code with bugs! LOL :-) then we might never know the flaw existed, let alone get a fix, unless some cracker with ethics told the world when they found the flaw rather than keep the exploit to themselves.

  • by ahde ( 95143 ) on Thursday March 14, 2002 @06:03PM (#3165219) Homepage
    Its stupid to bring up the GPL or other open source licenses or argue about whether Microsoft is stealing code. I'm glad they use zlib. I'm glad they used portions of the BSD tcp/ip stack. I'm glad they decided to support (to the best of their ability) standards like C and HTML. I'm glad I don't have to depend on Microsoft anymore. But if they hadn't used open source programs I'd have never been exposed to other options except for the likes of Novell and Sun.

    The real issue is that there is now a direct comparison on a shared bug (for which no exploit exists yet, let's not forget -- it's still theoretical) in both the free and proprietary systems.

    You can see the cooperation and disclosure *and* resolution on the open source side. Did Microsoft even admit to the vulnerability which they surely (one hopes) knew existed in their own systems? No. That's not the issue either.

    The great benefit that comes to open source from this is that now you can observe the different security and development models in action from a purely objective point of view.

    Fortunately, for Microsoft and their customers at least, this is not so serious a flaw that it will likely be exploited before they can get fixes out -- if they really want to. Even more fortunately for Microsoft, there are already enough vulnerabilities with easy and existing exploits, that the zlib vulnerabilities will probably be a non-issue. Hackers will tend to follow the path of least resistance.
    • Did Microsoft even admit to the vulnerability which they surely (one hopes) knew existed in their own systems? No.

      Did it occur to you *why* they haven't said anything?

      Because this bug doesn't pose a security risk in Windows.

      You're comparing apples and oranges... in Linux, this was a critical issue because linux's free() will quite happily trash your heap if you give it a chance. Under BSD and Windows, this is not a critical issue, because both BSD and Windows have marginally slower (but much safer) free() calls which will not trash your heap on a double free.

      This bug (might) exist in the mentioned windows software, but it is a completely harmless bug, thus there is no reason to issue patches immediately.
    • The issue, imho, isn't that MS uses open-source. That's what it's for after all. The issue is that MS uses open-source for its own advantage, while seeking to hurt the open-source movement whenever they do something that's not to MS's liking.

      Basically, while we shouldn't believe what they say, we should force them to act as if they do.

      Their PR flack recently said that OS software costs society by not hiring programmers or contributing to tax money. So they should immediately rip out all the open source software they use and hire programmers to recreate it.

      If they don't, can they really expect to have any credibility left?
  • Can someone please explain why zdnet and news, etc. are all on a non-existent domain?

    ; > DiG 9.2.0rc3 > news.com.com
    ;; global options: printcmd
    ;; Got answer:
    ;; ->>HEADER

    I don't get it. com.com seems to be some kind of travel agency. Any ideas?

    (Sorry for the offtopic question)

If you think nobody cares if you're alive, try missing a couple of car payments. -- Earl Wilson

Working...