Page 1 of 3

1353: "Heartbleed"

Posted: Wed Apr 09, 2014 5:59 am UTC
by rhomboidal
Image

Title Text: I looked at some of the data dumps from vulnerable sites, and it was ... bad. I saw emails, passwords, password hints. SSL keys and session cookies. Important servers brimming with visitor IPs. Attack ships on fire off the shoulder of Orion, c-beams glittering in the dark near the Tannhäuser Gate. I should probably patch OpenSSL.

I don't think there's enough earth in the Earth for clay tablets to store all the erotic fanfiction online.

Re: 1353: "Heartbleed"

Posted: Wed Apr 09, 2014 6:14 am UTC
by ManaUser
I like how the people that found it created not only a catchy name, but a matching logo. Not many people take the time to do that anymore... actually has anyone taken the time to do that before?
heartbleed.png
heartbleed.png (7.61 KiB) Viewed 17116 times

Re: 1353: "Heartbleed"

Posted: Wed Apr 09, 2014 6:17 am UTC
by Djehutynakht
I suppose it definitely helps to get the word out considering how huge the leak appears to be.

I guess I have to go shore up my defenses now...

Re: 1353: "Heartbleed"

Posted: Wed Apr 09, 2014 6:22 am UTC
by ChronosDragon
I don't think any of my sites were running OpenSSL. Eh, it's not like I had anything important there. Besides, my erotic fanfiction needed a wider readership anyway.

Re: 1353: "Heartbleed"

Posted: Wed Apr 09, 2014 6:37 am UTC
by Jamaican Castle
The superstitious among us might wonder what they expected when they made a security protocol with "open" in the name.

Re: 1353: "Heartbleed"

Posted: Wed Apr 09, 2014 6:45 am UTC
by addams
Welcome to my world, World.

Paranoid?
Nah. They, really, are out to 'Get' me.

They went after my paper and clay tablets, too.
***Nothing is sacred; Nothing is safe.***

Re: 1353: "Heartbleed"

Posted: Wed Apr 09, 2014 6:52 am UTC
by Rombobjörn
Heartbleed is yet another example of why coding in C is a bad idea. A memcpy with an incorrect size caused all this because C compilers do no bounds checking. Heartbleed wouldn't have happened if OpenSSL had been written in, for example, Ada. Instead of an information leak that leaves no trace it would have been a denial of service at the worst.

Re: 1353: "Heartbleed"

Posted: Wed Apr 09, 2014 7:08 am UTC
by CocoaNutCakery
Does anyone have a link to the data dumps or a list of affected sites? I'd like to know if any of the sites I use were affected.

Edit: Found this. Anyone have an updated version?

Re: 1353: "Heartbleed"

Posted: Wed Apr 09, 2014 7:44 am UTC
by eidako
This comes on the heels of DynDNS announcing that they will be discontinuing their free DDNS service in a month, which has only been available for the last year or so for those who were grandfathered into it. The universe seems to be telling me that it's time to shut off the private server...having a reasonable expectation that my instant messages weren't being read by the NSA was fun while it lasted.

Re: 1353: "Heartbleed"

Posted: Wed Apr 09, 2014 8:16 am UTC
by panthersnbraves
Attack ships on fire off the shoulder of Orion, c-beams glittering in the dark near the Tannhäuser Gate.

Classic! I could feel the rain.

Re: 1353: "Heartbleed"

Posted: Wed Apr 09, 2014 8:28 am UTC
by stankyjim
It is pretty important to realise that this isn't a web security bug. It is an issue with the TLS implementation of openssl versions 1.0.1a-f.

This impacts email, web, irc, databases, performance monitoring daemons, anything that uses the openssl TLS implementation and is of a vulnerable version.

Re: 1353: "Heartbleed"

Posted: Wed Apr 09, 2014 8:55 am UTC
by polterbyte
Logged in just to point out the Blade Runner reference.

One of my favorite monologues ever.

Re: 1353: "Heartbleed"

Posted: Wed Apr 09, 2014 8:59 am UTC
by Devil N
Rombobjörn wrote:Heartbleed is yet another example of why coding in C is a bad idea. A memcpy with an incorrect size caused all this because C compilers do no bounds checking. Heartbleed wouldn't have happened if OpenSSL had been written in, for example, Ada. Instead of an information leak that leaves no trace it would have been a denial of service at the worst.

It's yet another example of why poorly written code is a bad idea. No amount of programming languages and frameworks is going to protect you from incompetent programmers.

Re: 1353: "Heartbleed"

Posted: Wed Apr 09, 2014 9:10 am UTC
by Jamaican Castle
Devil N wrote:No amount of programming languages and frameworks is going to protect you from incompetent programmers.


Whenever you create a foolproof system, the universe just goes and makes a bigger fool to goof it up.

Re: 1353: "Heartbleed"

Posted: Wed Apr 09, 2014 9:35 am UTC
by Yu_p
@Jamaican Castle: Its more about noticing weaknesses while under stress than incompetence. Higher level languages typically make certain dangerous bugs impossible and reduce the code clutter that may hide the important parts.

I just wouldn't know which language to choose other than C for a long-running open source project, where performance may be critical. All alternatives I can think of raise question marks about the long-time stability of the language* or possible patent issues**.
____________________________________
* E.g. slow migration from Python 2.x to 3.x
** E.g. Google vs Oracle regarding Java

Re: 1353: "Heartbleed"

Posted: Wed Apr 09, 2014 9:58 am UTC
by balthasar_s
eidako wrote:This comes on the heels of DynDNS announcing that they will be discontinuing their free DDNS service in a month, which has only been available for the last year or so for those who were grandfathered into it. The universe seems to be telling me that it's time to shut off the private server...having a reasonable expectation that my instant messages weren't being read by the NSA was fun while it lasted.

There are other free DDNS services. I use dnsdynamic.org for my bicyclesonthemoon.dnsd.info

Re: 1353: "Heartbleed"

Posted: Wed Apr 09, 2014 10:09 am UTC
by bachaddict
The third Google result for heartbleed is a testing service. The sixth is this comic.

What do you have to do? Google, Facebook etc are secure, but if you used the same password on them as on a small site that's vulnerable, you're wide open.

Re: 1353: "Heartbleed"

Posted: Wed Apr 09, 2014 10:54 am UTC
by CocoaNutCakery
bachaddict wrote:The third Google result for heartbleed is a testing service. The sixth is this comic.

What do you have to do? Google, Facebook etc are secure, but if you used the same password on them as on a small site that's vulnerable, you're wide open.


Supposedly, Google is actually only secure now. It was actually unsecure during the time when Heartbleed was in effect, but unknown (or when it was just known).

The major problem is not what to do about sites that are secure now, but what to do about sites that are currently unsecure. For the secure ones, I'm updating my password, but I want to hold off on that for the currently unsecure sites.

Edit: They laughed when I used hotmail for my e-mail service. Well, who's laughing now? MUAHAHAHAHAHAHAHAHAHAHAHAHAHAHA

Re: 1353: "Heartbleed"

Posted: Wed Apr 09, 2014 11:18 am UTC
by Philbert
I am not a security expert. But if Heartbleed makes stuff readable from server memory, wouldn't an attacker still need command line access on the web server? Getting such access should be hard, right? Doesn't that make this problem less severe than it is drummed up to be?

Re: 1353: "Heartbleed"

Posted: Wed Apr 09, 2014 11:27 am UTC
by veit
panthersnbraves wrote:Attack ships on fire off the shoulder of Orion, c-beams glittering in the dark near the Tannhäuser Gate.

Classic! I could feel the rain.

Yes!
https://en.wikipedia.org/wiki/Tears_in_rain_soliloquy (Blade Runner spoilers...)

Re: 1353: "Heartbleed"

Posted: Wed Apr 09, 2014 11:48 am UTC
by stankyjim
Philbert wrote:wouldn't an attacker still need command line access on the web server? Getting such access should be hard, right? Doesn't that make this problem less severe than it is drummed up to be?


Security expert here!

Nope command line access is not needed, after a connection is established and TLS encryption negotiated the client requests a heart beat keep alive to take place. If the client requests an oversized keep alive reply, the server will respond with data which due to a bug contains a portion of the server's operational memory.

This process is repeated over and over again until the attacker has however much memory as they desire.

This vulnerablity is likely the most devastating that we have seen in the past decade.

Re: 1353: "Heartbleed"

Posted: Wed Apr 09, 2014 12:58 pm UTC
by Mazzula
rhomboidal wrote:I don't think there's enough earth in the Earth for clay tablets to store all the erotic fanfiction online.

Does it have to be clay tablets? Is IIS simply unthinkable?

Re: 1353: "Heartbleed"

Posted: Wed Apr 09, 2014 1:56 pm UTC
by forward4
I'm assuming because of the unique awareness that we have, the forums are secure...

Re: 1353: "Heartbleed"

Posted: Wed Apr 09, 2014 2:07 pm UTC
by ahammel
bachaddict wrote:What do you have to do? Google, Facebook etc are secure, but if you used the same password on them as on a small site that's vulnerable, you're wide open.

1) Never do that.
2) Use two-factor.
3) Update all your passwords for patched websites. Don't use the same one for all of them. Seriously.

Re: 1353: "Heartbleed"

Posted: Wed Apr 09, 2014 2:09 pm UTC
by Rombobjörn
Devil N wrote:
Rombobjörn wrote:Heartbleed is yet another example of why coding in C is a bad idea. A memcpy with an incorrect size caused all this because C compilers do no bounds checking. Heartbleed wouldn't have happened if OpenSSL had been written in, for example, Ada. Instead of an information leak that leaves no trace it would have been a denial of service at the worst.

It's yet another example of why poorly written code is a bad idea. No amount of programming languages and frameworks is going to protect you from incompetent programmers.

Programmers are human. Humans make mistakes. C is designed for superhuman programmers who never ever make a mistake. Ada is designed to help the programmer to find the mistakes as early as possible, and to reduce the harm done by those errors that still slip through.

Jamaican Castle wrote:Whenever you create a foolproof system, the universe just goes and makes a bigger fool to goof it up.

The bigger fool in this context would be a programmer who is foolhardy enough to tell the compiler to disable bounds checking. Such fools exist, but there are also programmers who are smart enough not to do that, but still make mistakes now and then that an Ada compiler can help them catch.

Yu_p wrote:I just wouldn't know which language to choose other than C for a long-running open source project, where performance may be critical. All alternatives I can think of raise question marks about the long-time stability of the language or possible patent issues.

Ada is a very backwards-compatible language. A few new reserved words have been added in new versions of the language, so if you happened to be using one of those words as an identifier you would have to change it, but most Ada 83 programs should be compilable as Ada 2012 without changes. I have never heard of any patent issues with the language Ada, and I believe I would have heard of them if there were any. And since Ada is normally compiled to machine code its performance is similar to that of C.

Re: 1353: "Heartbleed"

Posted: Wed Apr 09, 2014 2:10 pm UTC
by DaveMcW
forward4 wrote:I'm assuming because of the unique awareness that we have, the forums are secure...

The forums don't use SSL, so they are secure from the heartbleed bug.

Of course that means your forum password is available to anyone who wiretaps your internet connection...

Re: 1353: "Heartbleed"

Posted: Wed Apr 09, 2014 2:25 pm UTC
by addams
Devil N wrote:
Rombobjörn wrote:Heartbleed is yet another example of why coding in C is a bad idea. A memcpy with an incorrect size caused all this because C compilers do no bounds checking. Heartbleed wouldn't have happened if OpenSSL had been written in, for example, Ada. Instead of an information leak that leaves no trace it would have been a denial of service at the worst.

It's yet another example of why poorly written code is a bad idea. No amount of programming languages and frameworks is going to protect you from incompetent programmers.

ok. Is that funny?

Incompetent Programers?
Are Incompetent Programers the Gangsters of the Internet?

Are they Fucking idiots?
Do they leave a wake of fear and subtle destruction behind them?

Hi. I am Addams and I wander Off Topic.

Spoiler:
Are Incompetent Programers fundamentally incompetent?
Are they able and willing to Brute Force stuff Competent Persons would not do?

Incompetent Programers are the Gangsters of the Internet?
Is there a large portion of persons that are Both?

Incompetent Programers and 3D Gangsters?
Some Gangsters are Smart. Not most; Some.

We have Gangsters in My Nation and a Lot of Them.
Some are pretending. Many, Many are not.

When I look at my 3D world and the persons in it.
I, sometimes, see a very Flat Organization. ick.

Competent Individuals seem rare.
Competent Individuals should be Common.

How do you measure Competence in Programers?
How do you measure Competence in 3D Citizens?

Re: 1353: "Heartbleed"

Posted: Wed Apr 09, 2014 2:57 pm UTC
by dp2
Philbert wrote:I am not a security expert. But if Heartbleed makes stuff readable from server memory, wouldn't an attacker still need command line access on the web server? Getting such access should be hard, right? Doesn't that make this problem less severe than it is drummed up to be?

Nope.

In a nutshell, an OpenSSL connection uses a heartbeat to keep the connection open. That is, the two sides send a message back and forth to let each other know they're still there. The nature of this heartbeat message is a size and some data. One side sends the data, the other side sends the SAME data back.

The trick is, there's no check that the size and the data match. So, one side can say "Here's 64K bytes, send the same 64K back to me" but only actually send one byte of data. The other side puts that single byte in memory, not knowing it's only one byte. Then, knowing it has to send 64K back, it puts that same byte PLUS the next (64K - 1) bytes from its memory into the packet and sends it back. All those extra bytes can be anything in memory. It might be junk, but it can very easily be valuable info. And this happens with every heartbeat.

Re: 1353: "Heartbleed"

Posted: Wed Apr 09, 2014 3:33 pm UTC
by KarenRei
Yu_p wrote:I just wouldn't know which language to choose other than C for a long-running open source project, where performance may be critical. All alternatives I can think of raise question marks about the long-time stability of the language* or possible patent issues**.


C++ and STL containers? Long term stability, no patent issues, and generally excellent performance. I'd wager it's more common for people's performance to *improve* when switching to STL containers than slow down because of the amount of thought and work that goes into making the algorithms that deal with them fast. And the C++ standard has been evolving specifically to take out any potential bottlenecks that might slow them down versus raw C pointer-based implementations - for example, move constructors and the like. And if there's something about them that doesn't meet your needs (performance, implementation details, etc), you can subclass and make use of the raw data. And if you decide that the type of data structure you're using is no longer suitable, it's much easier to change the underlying mechanism without changing lots of code. And they're much easier to thread (many types are inherently threadsafe), esp. with the latest standards, where you can write a relatively simple one-line lambda to execute any function over a whole structure in the background, or even a future which will ensure that it's done executing by the time you next need to use the value without you having to manually tell it to finish. And on and on. Plus the obvious - typesafe, leakproof unless you do something really weird, templateable, etc.

They're not perfect, of course - they have their own types of errors you can make, such as trying to use invalidated iterators. You have to learn the language to use them right. But they're not prone to "casual" mistakes, like forgetting to include a free or bounds check, and the errors tend to be exceptions, not silent leaks/corruption.

Re: 1353: "Heartbleed"

Posted: Wed Apr 09, 2014 3:36 pm UTC
by gsilverfish
So as an end user I'm confused. Do I just wait for my sites to email me when it's time to change the password? If I understand correctly there won't be much point to it until they update things on their end.

Re: 1353: "Heartbleed"

Posted: Wed Apr 09, 2014 3:47 pm UTC
by addams
dp2 wrote:
Philbert wrote:I am not a security expert. But if Heartbleed makes stuff readable from server memory, wouldn't an attacker still need command line access on the web server? Getting such access should be hard, right? Doesn't that make this problem less severe than it is drummed up to be?

Nope.

In a nutshell, an OpenSSL connection uses a heartbeat to keep the connection open. That is, the two sides send a message back and forth to let each other know they're still there. The nature of this heartbeat message is a size and some data. One side sends the data, the other side sends the SAME data back.

The trick is, there's no check that the size and the data match. So, one side can say "Here's 64K bytes, send the same 64K back to me" but only actually send one byte of data. The other side puts that single byte in memory, not knowing it's only one byte. Then, knowing it has to send 64K back, it puts that same byte PLUS the next (64K - 1) bytes from its memory into the packet and sends it back. All those extra bytes can be anything in memory. It might be junk, but it can very easily be valuable info. And this happens with every heartbeat.

So interesting.
So clear.
It makes perfect sense.

Machines might work like that.
Now; How to trigger specific parts of Memory?

What fun.
If geneticists can Trigger specific parts of a gene sequences,
You can Trigger specific parts of Memory sequences.

Even if your explanation is not Real;
It's funny.

Re: 1353: "Heartbleed"

Posted: Wed Apr 09, 2014 3:49 pm UTC
by dp2
gsilverfish wrote:So as an end user I'm confused. Do I just wait for my sites to email me when it's time to change the password? If I understand correctly there won't be much point to it until they update things on their end.

That's correct. You can pester sites to get it fixed, and you can keep an eye on your money via non-web means. But as a user, there's nothing for you to do.

http://www.cnet.com/news/how-to-protect ... bleed-bug/

Re: 1353: "Heartbleed"

Posted: Wed Apr 09, 2014 3:49 pm UTC
by Rysto
ManaUser wrote:I like how the people that found it created not only a catchy name, but a matching logo. Not many people take the time to do that anymore... actually has anyone taken the time to do that before?

I like how they created a catchy name and a logo, but apparently couldn't be bothered to notify major OS vendors before disclosing the vulnerability.

Re: 1353: "Heartbleed"

Posted: Wed Apr 09, 2014 3:51 pm UTC
by dp2
addams wrote:
dp2 wrote:
Philbert wrote:I am not a security expert. But if Heartbleed makes stuff readable from server memory, wouldn't an attacker still need command line access on the web server? Getting such access should be hard, right? Doesn't that make this problem less severe than it is drummed up to be?

Nope.

In a nutshell, an OpenSSL connection uses a heartbeat to keep the connection open. That is, the two sides send a message back and forth to let each other know they're still there. The nature of this heartbeat message is a size and some data. One side sends the data, the other side sends the SAME data back.

The trick is, there's no check that the size and the data match. So, one side can say "Here's 64K bytes, send the same 64K back to me" but only actually send one byte of data. The other side puts that single byte in memory, not knowing it's only one byte. Then, knowing it has to send 64K back, it puts that same byte PLUS the next (64K - 1) bytes from its memory into the packet and sends it back. All those extra bytes can be anything in memory. It might be junk, but it can very easily be valuable info. And this happens with every heartbeat.

So interesting.
So clear.
It makes perfect sense.

Machines might work like that.
Now; How to trigger specific parts of Memory?

What fun.
If geneticists can Trigger specific parts of a gene sequences,
You can Trigger specific parts of Memory sequences.

Even if your explanation is not Real;
It's funny.

Oh, it's real. The saving grace, such as it is, is that a user of this exploit can't target specific parts of memory. They just get whatever random information happened to be next to the address where the heartbeat data was stored.

Re: 1353: "Heartbleed"

Posted: Wed Apr 09, 2014 3:57 pm UTC
by jkar
Wouldn't two-factor authentication be compromised as well, until/unless the service changed the private key? I was under the impression this vulnerability could reveal private keys for such things.
And if the site you use 2-factor for DOES change the key, wouldn't you need to change the key on your end as well? This part I'm less sure about because I really am not a cryptographer...

It also seems like all of my attempts at posting are being flagged as spam for no clear reason, so I can't even post my question which is the sole reason I made an account. Brilliant.

Re: 1353: "Heartbleed"

Posted: Wed Apr 09, 2014 4:20 pm UTC
by poslundc
You guys can debate the merits of programming languages all you want. Anywhere that human interaction is required there is the potential for bugs. This wasn't a failure of language choice, it was more than likely a failure of process. Any mission-critical code like this should've been reviewed line-by-line by at least one other programmer before shipping. Any C/C++ programmer worth their salt would've red-flagged an arbitrary memcpy like that.

Dan.

Re: 1353: "Heartbleed"

Posted: Wed Apr 09, 2014 4:22 pm UTC
by jpvlsmv
dp2 wrote:
addams wrote:
dp2 wrote:
Philbert wrote:I am not a security expert. But if Heartbleed makes stuff readable from server memory, wouldn't an attacker still need command line access on the web server? Getting such access should be hard, right? Doesn't that make this problem less severe than it is drummed up to be?

Nope.

In a nutshell, an OpenSSL connection uses a heartbeat to keep the connection open. That is, the two sides send a message back and forth to let each other know they're still there. The nature of this heartbeat message is a size and some data. One side sends the data, the other side sends the SAME data back.

The trick is, there's no check that the size and the data match. So, one side can say "Here's 64K bytes, send the same 64K back to me" but only actually send one byte of data. The other side puts that single byte in memory, not knowing it's only one byte. Then, knowing it has to send 64K back, it puts that same byte PLUS the next (64K - 1) bytes from its memory into the packet and sends it back. All those extra bytes can be anything in memory. It might be junk, but it can very easily be valuable info. And this happens with every heartbeat.

So interesting.
So clear.
It makes perfect sense.

Machines might work like that.
Now; How to trigger specific parts of Memory?

Oh, it's real. The saving grace, such as it is, is that a user of this exploit can't target specific parts of memory. They just get whatever random information happened to be next to the address where the heartbeat data was stored.

Right, and that's the part that's not being made clear in the mass-media version of "The Sky Has Fallen" reporting on this bug (as well as on the actual tech side.

Yes, you will get 64k of memory from the server. But you don't control which 64k1. And even if you happen to get the server's key, that string of bytes is (should be) indistinguishable from 8192 bits from /dev/random (except that you can test it to see if it happens to decrypt something, or match the signature on a certificate)

--Joe
[1] It depends on where your dynamic memory allocator decides to put the 1 byte (in this example) Alice sent to Bob's server. It would have to be in a lower address within 64k of the data you actually want. Your placement will usually be influenced by the size of the allocation (1byte may be far away from a 4-byte allocation) and how fragmented the server's memory is (i.e. how busy it has been since it started), and you may still crash the server process if you read past the end of a memory page into unallocated space.

Re: 1353: "Heartbleed"

Posted: Wed Apr 09, 2014 4:32 pm UTC
by addams
poslundc wrote:You guys can debate the merits of programming languages all you want. Anywhere that human interaction is required there is the potential for bugs. This wasn't a failure of language choice, it was more than likely a failure of process. Any mission-critical code like this should've been reviewed line-by-line by at least one other programmer before shipping. Any C/C++ programmer worth their salt would've red-flagged an arbitrary memcpy like that.

Dan.

Wonderful!
Two more Posts and you can join the Conversation with full Linking Powers!

Yes! You know how to fix the vulnerabilities of Human Interactions with Machines?
How? Many have considered disposing of the Human Interface.

What fun would that be?
You want to Add more Programers?

Good Idea!
(please keep in mind, programers are people, too.)

Re: 1353: "Heartbleed"

Posted: Wed Apr 09, 2014 4:50 pm UTC
by spoonyspork
CocoaNutCakery wrote:
bachaddict wrote:The third Google result for heartbleed is a testing service. The sixth is this comic.

What do you have to do? Google, Facebook etc are secure, but if you used the same password on them as on a small site that's vulnerable, you're wide open.


Supposedly, Google is actually only secure now. It was actually unsecure during the time when Heartbleed was in effect, but unknown (or when it was just known).

The major problem is not what to do about sites that are secure now, but what to do about sites that are currently unsecure. For the secure ones, I'm updating my password, but I want to hold off on that for the currently unsecure sites.

Edit: They laughed when I used hotmail for my e-mail service. Well, who's laughing now? MUAHAHAHAHAHAHAHAHAHAHAHAHAHAHA


Fun fact: hotmail used to plop your username and password right on the url created on login, not obscured in any way (IIRC the url read something like 'hotmail.com/uid=<username>&pwd=<password>' or something equally as absurd). I could actually tell when my mom was lying about triple-checking to make sure she'd typed her password correctly when she'd complain she couldn't log in. Fun times, man. Fun times.

*re-lurks -- just here to change password on yet another site, just in case*

Re: 1353: "Heartbleed"

Posted: Wed Apr 09, 2014 4:54 pm UTC
by poslundc
addams wrote:
poslundc wrote:You guys can debate the merits of programming languages all you want. Anywhere that human interaction is required there is the potential for bugs. This wasn't a failure of language choice, it was more than likely a failure of process. Any mission-critical code like this should've been reviewed line-by-line by at least one other programmer before shipping. Any C/C++ programmer worth their salt would've red-flagged an arbitrary memcpy like that.

Dan.

Wonderful!
Two more Posts and you can join the Conversation with full Linking Powers!

Yes! You know how to fix the vulnerabilities of Human Interactions with Machines?
How? Many have considered disposing of the Human Interface.

What fun would that be?
You want to Add more Programers?

Good Idea!
(please keep in mind, programers are people, too.)


I'm an engineer; I don't value quantity over quality. I'm specially trained to write code of sufficient quality for use in pacemakers, medical lasers and space shuttles, where it has to work correctly the first time and every time. My undergrad thesis was software to monitor a nuclear reactor. But hey, I'm only five thousand posts away from being worthy to be a part of the conversation. Good to see this is where the intellectuals hang out; I'm real thrilled to be here.

Dna.