Slow Down the Security Patch Cycle?

trying to speed up by Anonymous Coward · 2004-04-13 07:30 · Score: 1, Funny

I'm trying to speed up the first post cycle.

Yes. by ImTwoSlick · 2004-04-13 07:32 · Score: 5, Funny

slowing down, not speeding up, patch releases

We all know how well that works for MS Outlook.

Re:Yes. by Frymaster · 2004-04-13 07:43 · Score: 5, Interesting

We all know how well that works for MS Outlook.
the obvious solution is to distribute patches via an outlook virus. it seems to be the only distro method that's guarnteed to work.

--
2 1337 4 u!
Re:Yes. by mst76 · 2004-04-13 07:52 · Score: 4, Funny

Huh? I though they already did this. I got an email from MS with an attachment that promised to patch all security issues :).
Re:Yes. by Anonymous Coward · 2004-04-13 08:22 · Score: 0

How bout slowing down releases so that there is more time to produce a stable product that requires less patching?

Oh wait, that's the dreamer in me speaking...
Re:Yes. by Geoffreyerffoeg · 2004-04-13 08:27 · Score: 1

Although you meant it humorously, that would probably be an effective solution. Distribute an attachment that contains a self-replicator and a downloader stub for the latest security patch every time one comes out. Let there be a simple self-propagation scheme that requires the file to be digitally signed from Microsoft, and user permission / permission granted in EULA.
Re:Yes. by fprog · 2004-04-13 11:44 · Score: 0

What his needed is a KDE applet or equivalent
Gnome program that bugs the user every week,
to update software on his machine.

Like Antivir or Spybot on Windows or anyother "smart" antivirus...
That's quite efficient method of doing things.
You just cannot forget it.

Basically,
it connects to a mirror
check the version,
if lower download it (wget),
check MD5 sum,
ask for root password,
install a binary patch...
Case close.

Why people have to "figure out" there's a patch/exploit out there,
try to apply the patch,
doesn't work RPM dependancy hell or similar,
try to compile from source, incompatible glibc...
Just donwload a statically linked binary files or all dynamicaly linked binary files.

Patching a kernel or a running deamon is in the same category... hell.

It should be as easy as: 'apachectl graceful'

'kernelctl graceful' anyone?

Just my 2cents.
Re:Yes. by krewemaynard · 2004-04-14 01:10 · Score: 1

Distribute an attachment that contains a self-replicator and a downloader stub for the latest security patch every time one comes out. Let there be a simple self-propagation scheme that requires the file to be digitally signed from Microsoft, and user permission / permission granted in EULA.
thanks but no thanks....imagine the bandwidth that would require! if they did that for even just the critical patches, networks would grind to a halt.

easy patch: c:\fdisk c:

--krewe

--
I saw it on Slashdot, it must be true!
Re:Yes. by Anonymous Coward · 2004-04-16 22:36 · Score: 0

Not if multicast was used. But that would involve ISPs allowing multicast routing to the home user - and, as most American ISPs are cable TV companies, they're not going to do it without severe pressure, as multicast is also ideal for video delivery over the internet...

I don't think you'll get an argument from MS by Anonymous Coward · 2004-04-13 07:32 · Score: 5, Funny

Any slower and Microsoft would just start shipping exploits instead of patches.

Re:I don't think you'll get an argument from MS by Jason+Straight · 2004-04-13 07:43 · Score: 4, Funny

They already do!
Re:I don't think you'll get an argument from MS by pegr · 2004-04-13 08:21 · Score: 4, Insightful

Any slower and Microsoft would just start shipping exploits instead of patches.

This is essentially the point of the author...

"They [hackers] wait until the patch for the vulnerability is released, then they reverse-engineer the patch. This is orders of magnitude easier than finding the vulnerability directly."

I believe this idea is flawed. A general description may give a would-be "zero-day hax0r" a place to look, but patches are distributed not as patches to individual files (e.g. diffs) but as whole file replacements.

To further reflect the sophistication of the author, he also spews this gem:

"An exploit is a method devised to take advantage of a specific software vulnerability using a software virus, Trojan horse or worm. When the exploit is done without a virus, Trojan or worm, it's using an undocumented feature."

Conclusion? This guy is a putz...
Re:I don't think you'll get an argument from MS by _xeno_ · 2004-04-13 08:40 · Score: 5, Interesting

but patches are distributed not as patches to individual files (e.g. diffs) but as whole file replacements.
You are aware that with a complete copy of the original directories, even with "whole file replacements," you're now just one step away from getting a diff?
Although I still think patches should be released as soon as possible because even if they do help "crackers" (or whatever we're calling them today) find exploits, there are still very intelligent black hats who will eventually find the exploit and start spreading it around. Patching it faster may mean more exploits sooner, but it also means that people can patch against the flaw without waiting for some black hat to make the entire point moot.

--
You are in a maze of twisty little relative jumps, all alike.
Re:I don't think you'll get an argument from MS by bitspotter · 2004-04-13 09:23 · Score: 1

patches are distributed not as patches to individual files (e.g. diffs) but as whole file replacements.

You're right. Everyone knows crackers are too lazy to make their own diff.
Re:I don't think you'll get an argument from MS by Anonymous Coward · 2004-04-13 10:11 · Score: 1, Informative

You mean crackers in lieu of hackers, don't you.
Re:I don't think you'll get an argument from MS by Anonymous Coward · 2004-04-13 11:24 · Score: 0

You are aware that with a complete copy of the original directories, even with "whole file replacements," you're now just one step away from getting a diff?

Thing is, even if you did just send a diff in the first place, a lot of things change when you relink after some piece of code gets larger or smaller. You've got all these modified addresses in there, polluting the diff, making the real change harder to find. Theoretically, there are ways of making this even worse. (esp. if you could throw a little insignificant randomness into the compiler)
Re:I don't think you'll get an argument from MS by hallaballa · 2004-04-13 17:11 · Score: 1

(posting in interest of accuracy, not of smart-ass-ness) Actually, they are increasingly being distributed as diffs. I guess the idea is to increase the chance of 56k-ers actually installing patches.

The good news is -- modem-users might actually patch. The bad news is that more disk space might be wasted (to allow for roll back) and/or that users may need original media to install/rollback. Btw, SP2 contains policies to determine how much disk space is used for the base files (pre-patched files, used to roll back).
Re:I don't think you'll get an argument from MS by pegr · 2004-04-14 01:43 · Score: 1

You are aware that with a complete copy of the original directories, even with "whole file replacements," you're now just one step away from getting a diff?

Ouch! OK, I guess sometimes the obvious escapes me. I still stand by my original assertion, however. (Just remove the implication about not having diffs. ;) No one has taken issue with my conclusion anyway...
Re:I don't think you'll get an argument from MS by grupo-xenon · 2004-04-23 22:14 · Score: 1

Most people here didn't read the article.

There is at least one statment in the article where my tongue was firmly planted in my cheek. Changes by the editor made it into a nonsense statement.
As printed: When the exploit is done without a virus, Trojan or worm, it's using an undocumented feature.
Original: When the exploit is done without a virus, Trojan or worm, it's called "using an undocumented feature." (Which was a joke the ComputerWorld editor didn't get.... So putz yourself)

1) Please read the article before deciding what "Slow down" means.

2) The article states that patches for active exploits must be released immediately by the vendor. A number of readers missed that.

3) Microsoft with their scheduled "patch day" has implemented a pure "slow down" model -- and I think it is ineffective. People who don't update on the designated day are subject to the same vulnerabiites and having everyone hit the update site at the same time -- effectively creating a denial of service attack of Microsoft's own making. This, in turn, prevents users from updating on a timely basis. The article presents one possible solution to that problem.

Like Microsoft is doing? by JPriest · 2004-04-13 07:32 · Score: 4, Insightful

Everyone already decided this was a bad idea when Microsoft starting doing it. We can't change our minds and copy them because we all know Microsoft does not Innovate.

--
Saying Java is nice because it works on all OS's is like saying that anal sex is nice because it works on all genders.

Re:Like Microsoft is doing? by October_30th · 2004-04-13 07:35 · Score: 0, Flamebait

Spoken like a true slashbot.

--
The owls are not what they seem
Re:Like Microsoft is doing? by Kenja · 2004-04-13 07:36 · Score: 3, Insightful

This all just lends credence to my theory that the best way for Microsoft to kill Linux is for them to adopt it. Nothing would make the Linux Zealots jump ship faster. Within days we'd be hearing about how much Linux sucks and how BSD or some other OS is the "One True Operating System".

--

"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
Re:Like Microsoft is doing? by Anonymous Coward · 2004-04-13 07:40 · Score: 0

That would be pure evil. Effective, but evil.

As a BSD user, that would really suck.
Re:Like Microsoft is doing? by Anonymous Coward · 2004-04-13 07:50 · Score: 0

Evil so good...
I for one am sick of the open source hypocrisy.
I've tried Linux twice and on both accounts the installer did not recognize my hardware so I gave it up. Now I know a lot about computers so I can only imagine how bad Linux would be to a joe blow.
Re:Like Microsoft is doing? by Anonymous Coward · 2004-04-13 07:59 · Score: 1, Insightful

Knowing your hardware is the first step, you need to learn how your hardware works with Linux...hitting "Next" all the way through doesn't work like it does in Windows, you need to answer some questions first
Re:Like Microsoft is doing? by Anonymous Coward · 2004-04-13 08:04 · Score: 1, Funny

The nuclear plant over there is so severely lacking security, it's not even funny anymore. Yesterday I'd sneaked in just for kicks and could have obtained 300 kilogram of fissionable material waiting in that truck there and no one had noticed.

But ssssshhhh, don't tell anyone, not the police, not the management and definetly not the public. Just let it be the way it is. If nobody except you and me know about this, nothing bad will happen, I swear!
Re:Like Microsoft is doing? by Anonymous Coward · 2004-04-13 08:09 · Score: 0

Microsoft can go and adapt it if it wants, just as long as it leaves us alone. I don't want any grubby proprietary hands mucking around with linux. Live free or die!
Re:Like Microsoft is doing? by Anonymous Coward · 2004-04-13 08:15 · Score: 0

Huh?
Why should I care about how my hardware works whether I am running Linux or Windows?
Hitting "Next", as you described it, has served me perfectly in the past. The one thing I've really liked in Windows is that I don't have to care about IRQ and DMA like in DOS.
Re:Like Microsoft is doing? by Anonymous Coward · 2004-04-13 09:18 · Score: 0

The IRQ numbers are basically meaningless on a modern system. Maybe re-assess your expertness because you're viewing the world through 20 year old assumptions.
Re:Like Microsoft is doing? by dotKAMbot · 2004-04-13 09:39 · Score: 1

That is why linux isn't for you... Use windows or Mac and stop complaining about how one of the 50 million linux installers sucks.

Why do non GNU/Linux or non *BSD users feel it is so important to constantly bring up why linux or BSD isn't good enough? What they are really saying is that it isn't right for their uses.

I guess the same could be said for the Linux and BSD users. So my question is: Why are people so full of themselves and their OS's?

peez
Re:Like Microsoft is doing? by Idarubicin · 2004-04-13 10:41 · Score: 2, Insightful

This all just lends credence to my theory that the best way for Microsoft to kill Linux is for them to adopt it. Nothing would make the Linux Zealots jump ship faster.
Actually, I'm pretty sure that most of the zealots would just be crowing about how "we won!" Microsoft distributing an operating system for which they are license-bound to also distribute the code? No hidden hooks for their own products? Bill Gates bowing down before the Altar of Linus?
The zealots would be thrilled.

--
~Idarubicin

I want it fixed ASAP by Gr33nNight · 2004-04-13 07:33 · Score: 4, Insightful

I dont know about everyone else, but if a bug or security hole is found, I want a patch for it ASAP, and not in 2 months when the next 'service pack' or whatever comes out.

I dont think the issue has to do with patches coming out all the time, but having a better way to install said patches. Lets just say I am really looking forward to Novells Zenworks Patch Management solution.

Re:I want it fixed ASAP by cK-Gunslinger · 2004-04-13 07:49 · Score: 4, Insightful

But that's part of the problem (according to the article.) When a software company releases a patch, it's not just the customers who receive it, but all the virus/worm writers. If they can reverse-engineer the patch and come up with an exploit faster than it takes for *all* the customers to apply the patch, they win. And trust me, they will *always* beat the masses, as long as there are people out there who seldom/never patch their systems.

Perhaps all software patches should be about 1GB in size, mostly consisting of random crap, with the little patch embedded deep inside. ;)
Re:I want it fixed ASAP by foxyLady · 2004-04-13 07:53 · Score: 2

i think people are missing the point, and the point is: we need to write better software in the first place -- test it well BEFORE releasing it, not relying on the fact that we can release a patch later, after the bug is found by someone

i mean, if we only rely on someone finding the bug after the release and reporting it, we are in big trouble...who said that all the bugs found have been reported?

additionally, security is not something that can be fixed after the product is designed -- security is just as big of a part of the product design as is the product's functionality

thinking about software security during the design stage will prevent many bugs from being implemented, missed during testing, and then exploited...it will also save us from the necessity of patches
Re:I want it fixed ASAP by mapMonkey · 2004-04-13 07:54 · Score: 2, Insightful

If they can reverse-engineer the patch and come up with an exploit faster than it takes for *all* the customers to apply the patch, they win.

So, how does waiting longer to release the patch change that situation at all?
Re:I want it fixed ASAP by cK-Gunslinger · 2004-04-13 08:01 · Score: 1

So, how does waiting longer to release the patch change that situation at all?

Good question. I never really did see the answer to that, and now the article is /.'d. Perhaps because more people are likely to apply a large patch that "fixes 37 known security issues" than they are to apply 37 individual patches over a 3-6 month span.
Re:I want it fixed ASAP by magead7 · 2004-04-13 08:05 · Score: 2, Interesting

Just slowing it down by itself won't help. If the patches were all listed at some very convenient central location and everyone knew that the first of the month was patch day, maybe people would remember to patch. If it were some set day, each OS could pop up a little message saying to go get all of this month's patches. Additionally, if the patch schedule is random like it is now, then the exploiters are much more likely to hear about the patch than the average computer user. Having a set day might eliminate that advantage, assuming users do go get the patches on the right day.
Re:I want it fixed ASAP by pete-classic · 2004-04-13 08:05 · Score: 1

I'm pretty sure the author of this article is the same guy who told me he doesn't wear his seat-belt because of an anicdote about a person being "thrown clear" of a car wreck that burned up.

I'm not at all sure that slammer was written based on info gleaned from the patch.

I'm even less certain that, on the whole, waiting for a real world exploit before releasing a patch makes sense.

-Peter
Re:I want it fixed ASAP by canajin56 · 2004-04-13 08:06 · Score: 2, Funny

My girlfriend's younger sister never patches her machine. I was checking it out, it was an XP box with no patches applied, and the anti-virus table was from 2001! I said it was a bad idea. She said "Who cares. Oh no, they can read my school work and my e-mail! I'll just format every couple months when it gets too slow" Mind you, she gave us a ride, and after there was sweet smelling smoke pouring out of the hood. "You're burning anti-freeze" I say. Her response was "Yeah, its leaking all over everything, but it still runs"

--
ASCII stupid question, get a stupid ANSI
Re:I want it fixed ASAP by radish · 2004-04-13 08:11 · Score: 1

Even better, how about some little thing built into the OS which goes and fetches the patches automagically, and asks if you want to install them. Then the user doesn't have to do anything except click "install" when prompted. I wonder when someone will invent that.

--
---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"
Re:I want it fixed ASAP by Xentax · 2004-04-13 08:12 · Score: 4, Insightful

The article author suggests that the patch be distributed in an encrypted form, and then on a specified date, the key gets sent and everyone patches simultaneously.

Though if he really thinks that a patch in this form would be significantly harder to crack than a 'normal' patch, he's stretching.

Even if it was, the key would at least occasionally get leaked privately before it was publicly sent, and thus malware writers would have a field day.

All of that is also based on the assumption that exploit writers use the patch to reverse-engineer the vulnerability and exploit it. If this slower cycle he's proposing is too slow, there'll be plenty of "ne'er-do-wells" that will find vulnerabilities the old fashioned way. It's trading the current problem for yesterday's, not what I'd call a step in the right direction.

Working harder to make consumer machines and OSes able to intelligently patch themselves is a better solution. XPsp2 will switch Windows Update to "install by default" instead of "off by default", which will help there. Making it as transparent and yet as unobtrusive to Joe AverageComputerUser is, IMHO, the way to get the attack surface down from millions of machines to a few thousand or less.

The one thing I'll agree about as far as slowing the patch cycle down is that making sure any released patch DOES fix the problem and DOES NOT break other things in the process. Those are the kinds of arguments that various parties throw up when they're objecting to applying patches as soon as they're available (that's what was horribly badly wrong with the old NT service packs, for example -- they often broke applications and thus people would wait months or even stay a full service pack behind the latest version).

Xentax

--
You shouldn't verb words.
Re:I want it fixed ASAP by Anonymous Coward · 2004-04-13 08:24 · Score: 1, Insightful

Well put. There are probably hundreds of security patches per year across many vendors. The article's position is that drastic changes in the way patches are released are necessary based on one instance of a patch gone wrong. Not to say it is the only time that has happened, but he could have at least come up with a few more examples.
Re:I want it fixed ASAP by swordboy · 2004-04-13 08:28 · Score: 4, Insightful

I don't think that you are seeing the big picture.

Say, Microsoft finds a bug (either internally or via a good/trusted samaritan who will keep it private). Now, they go ahead and code up a patch for the bug but when do they release it?

Because the patch for blaster required Win2K SP2, many people were not able to protect themselves appropriately as SP2 is over 8 hours on a dial-up connection (more than half of the 'net). Now, if MS can get a "quarterly updates" on CD mailed to all of these people, then they can give everyone a better means of securing their boxen prior to letting the hackers pick apart the actual patch to find out what the hole is and how to exploit it (though blaster isn't a good example of a patch being reverse engineered into an exploit).

This is a HUGE dillemna for corporations. Especially those that have ooldes of laptops with users connecting via dial-up. I'm actually connected, as-we-speak (type?), to windowsupdate.com and have been for the past hour or so... ON BROADBAND...

What I would suggest is the best of both worlds - release patches only as exploits are found in the wild while compiling fixes for deployment en bulk. And you'd think that Microsoft, with billions in free cash, would start putting a bounty on some of this stuff (either reporting the holes themselves or the hackers that exploit them). It just shows how little Microsoft and Billy care about Joe User.

And how about some freakin' color schemes for XP? I mean, really... three whole color schemes?

--

Life is the leading cause of death in America.
Re:I want it fixed ASAP by rgmoore · 2004-04-13 08:31 · Score: 2, Interesting

What the author is proposing is that patches need to be distributed in two stages. First the distributor would pass out the patch itself, but with the wrinkle that it would be encrypted. The decryption key would only be released after a delay calculated to give people enough time to learn about the problem and download the patch.
The theory is that this gives the good guys an advantage in the information race. The distributor can give users plenty of time to find out about the patch and download it while still not providing the malware writers any usable information. When the decryption key is finally released, everyone should be able to download it in short order- the key itself is likely to be smaller than the network overhead it takes to transport it- and be done patching well before even a fast coder can understand the patch and turn it into a workable exploit.
There are still some obvious problems, of course. It won't work with the common Free Software development model, since the patches will still be visible. It also won't work for users who want to test a patch before trying it out on their production systems. It also depends on warnings about the vulnerability remaining vague enough that malware authors can't derive useful information from the warning. It may not be possible to find a vulnerability just because you know it's somewhere in a very large program, but once you know that it's localized in a particular subsystem there may be enough info to find it yourself.

--
There's no point in questioning authority if you aren't going to listen to the answers.
Re:I want it fixed ASAP by adamruck · 2004-04-13 08:48 · Score: 1

how about this, dont patch security holes that arent being exploited.

--
Selling software wont make you money, selling a service will.
Re:I want it fixed ASAP by rainman_bc · 2004-04-13 09:09 · Score: 1, Insightful

Disclaimer: there's good IT people out there, I just haven't worked with many. I'm ranting about the bad ones I've seen (about twenty I can think of right now)
<begin rant>
IT People insist on testing patches. I agree. Good idea. Truth be told, IT people I've seen generally find testing and applying patches quite boring. They'd much rather be running around the office yelling "security hole" at every idea that comes up, or bitching about the fact they don't have any time while they are chatting on messenger or writing posts on slashdot. Truth is, many IT people haven't the faintest clue what security means. Last one I saw was obsessed about throwing the web app behind a PIX firewall (which is a good idea), but was six months behind in server patches (which IMHO should have been higher on the priority list). No PIX will defend you against IIS holes.

In fact, he couldn't even produce valid backups for us each time he was asked to restore a backup. Clearly he needed to understand that security began with recovery. Once the recover plan's in place you worry about prevention. You can't prevent 100% of the attacks, but you can recover from 100% of them with the right plan. <end rant>

This will probably burn up my Karma even further, but whatever. I feel better

--
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
Re:I want it fixed ASAP by chris_mahan · 2004-04-13 09:31 · Score: 1

Let's say Mr UberKrach worms out your system and now your patches come via freenet.org, courtesy of some less-than reputable guy in the evil corner of an evil country (pick a continent) and you win machine merrily installs all that junk as "Microsoft patches"...

Oh, that gives me an idea... See ya'll later ;)

--
"Piter, too, is dead."
Re:I want it fixed ASAP by Anonymous Coward · 2004-04-13 09:55 · Score: 1, Funny

Your ideas intrigue me, and I would like to subscribe to your newsletter.
Re:I want it fixed ASAP by lcde · 2004-04-13 10:17 · Score: 1

Perhaps all software patches should be about 1GB in size, mostly consisting of random crap, with the little patch embedded deep inside. ;)

I've got dialup you insensitive clod :)

--
:%s/teh/the/g
Re:I want it fixed ASAP by Anonymous Coward · 2004-04-13 10:46 · Score: 0

I want a patch for it ASAP,
I assume that's why you did not even bother to RTFA, being in such a hurry? The concern voiced had little to do with practical chores of installing patches all the time; it was a completely different aspect he was worried about.
Go read the article, you insensitive clod!
Re:I want it fixed ASAP by aastanna · 2004-04-13 14:36 · Score: 1

yes...but if someone "worms out" your system, and changes things in ways you can't detect or fix, your screwed either way. Doesn't matter if you're automatically patching, manually patching, or running some command in a shell if you can't trust your system no matter what you do you could be running arbitrary code.
Re:I want it fixed ASAP by LincolnQ · 2004-04-13 16:32 · Score: 1

Tell her it hurts the Internet community at large if she is a spam relay. And it's not too hard to patch XP, so just DO it.
Re:I want it fixed ASAP by hallaballa · 2004-04-13 17:15 · Score: 1

"release patches only as exploits are found in the wild while compiling fixes for deployment en bulk"

-- but this would require customers to be on 'stand by' mode 24-7, since a critical patch may be released any second. It's better if world+dog *expects* and plans for patching, say, every 2nd tuesday each month. No?
Re:I want it fixed ASAP by Anonymous Coward · 2004-04-14 05:16 · Score: 0

"we need to write better software in the first place"

But, but... WHY????

Each day my new software delays from start selling is less money I earn. We live in a capitalist society, don't we? Comunism is bad, isn't it?

And security is not a concern for the public, as Microsoft clearly has demonstrated through the years...

So why in hell should I spend time and money at the developing stage, if it only will tend to release my software later, and loose the chance to stablish a wonderful "security network" to patch the bugs later so people see, day by day, how important is their security to us?
Re:I want it fixed ASAP by magead7 · 2004-04-14 05:16 · Score: 1

Windows automatic updating doesn't work well enough. It only updates a few Microsoft products. This leaves a ton of programs unupdated while giving a sense of security since the end user just sees updates being installed and probably has no clue that it isn't updating everything. Redhat does a better job, but the same problem still exists if you're not using a program they've included in their list.
Re:I want it fixed ASAP by foxyLady · 2004-04-14 09:52 · Score: 1

so, you wan to have the same reputation as microsoft? heh...
well, if that's what you want...

unfortunately, most of the companies do not have as much money as microsoft does, and thus have to spend it wisely

the wise thing to do would be to spend it on incorporating security into your product at the development stage rather than spending MORE money on successive patches

plus, as i already said, adding security later is like debugging badly written code -- sometimes it's just better to start over
Re:I want it fixed ASAP by Anonymous Coward · 2004-04-15 01:45 · Score: 0

What I would suggest is the best of both worlds - release patches only as exploits are found in the wild while compiling fixes for deployment en bulk.

Is this really feasible when the latest generation of "exploit" can spread in under an hour?

aa by Anonymous Coward · 2004-04-13 07:34 · Score: 0

Why would you need to slow down patch relases? more boxes to 0wN!!!

Just more astroturf by Anonymous Coward · 2004-04-13 07:34 · Score: 5, Insightful

While it doesn't name any names, the gist of this article is exactly the same as when Microsoft said that exploits only come after patches are released. This is patent nonsense and we all know it; - every week there's a few stories about a new MS hole that's being exploited but that they refuse to (or cannot) fix. I wonder why such a vapid article was posted?

Re:Just more astroturf by farmy · 2004-04-13 08:32 · Score: 1

So basically the gist of this article is that exploits come from patches. Um... therefore if we don't release patches, we wont have exploits? :P

This guys heart is in the right place, but vulnerability research doesn't just come from the good guys. Whether you release the patch or not, the vulnerability is there. Whether its publically known or not, it is and probably will be exploited. The only difference is you just don't know about it.

Patches by Anonymous Coward · 2004-04-13 07:35 · Score: 0

Patches Smatches! So what if my computer is used to DDOS SCO. Big Deal.

Re:Patches by cexshun · 2004-04-13 07:39 · Score: 1

Until a virus DDOSes Slashdot. Then we'll have geeks unite in a mob of tears and jeers. DDOS isn't good for anyone. Why is it only the bad people get no rights? Eventually the good people will also fall to the torment.
Re:Patches by Anonymous Coward · 2004-04-13 08:04 · Score: 0

What makes a person good or bad? If you are a slashdot monkey, do you become a good person? What a stupid view. It is good summary of how distorted slashdot monkies' brains are. Go outside, breathe and realize that you are not a good person, only an idiot who hangs around slashdot.
Re:Patches by cexshun · 2004-04-13 08:20 · Score: 1

I think you gravely misunderstood my post. I was referring to the fact that people cheer when a bad company is violated using illegal tactics, i.e. DDOS, but if it were to happen to say Slashdot.org or kernel.org, all of a sudden the attacker is evil. And perhaps you should check my post count before you begin drawing conclusions about my internet habits.

LMAO! by khasim · 2004-04-13 07:36 · Score: 3, Funny

First, let's define zero-day exploit. An exploit is a method devised to take advantage of a specific software vulnerability using a software virus, Trojan horse or worm. When the exploit is done without a virus, Trojan or worm, it's using an undocumented feature.
Undocumented feature? WTF?
It's a security hole! Not an "undocumented feature".
Hahahahahahahahaha!

Re:LMAO! by inode_buddha · 2004-04-13 07:48 · Score: 2, Funny

SARCASM_ON: Yeah, right. It was a feature. So we didn't document it. Hell, we didn't even advertise it. I run linux exclusively; and I'd expect patches the same day for any system I deal with, be it Mac, Windows, or anything else. Of course, I could always take my business elsewhere; I prefer to deal with those who stand behind their products, words, and actions, *without lawyers and weasel-wording*, which is why I prefer Open systems per se. They have a better track record, IMHO.

--
C|N>K
Re:LMAO! by spikev · 2004-04-13 07:48 · Score: 1

Unless it's a Cisco router. See here.
Re:LMAO! by devobelisk · 2004-04-13 07:55 · Score: 1

You ninny! Just because something is bad does not mean it is not a feature. I think you have mistaken an accepted definition: An item advertised or offered as particularly attractive or as an inducement: a washing machine with many features. With a more appropriate one: A prominent or distinctive aspect, quality, or characteristic: a feature of one's personality; a feature of the landscape. ... and of course it is undocumented or the software vendor would have removed the feature before shipping the product. All definitions blatantly stolen from http://dictionary.reference.com/search?q=feature
Re:LMAO! by Havokmon · 2004-04-13 08:30 · Score: 1

You ninny! Just because something is bad does not mean it is not a feature. I think you have mistaken an accepted definition: An item advertised or offered as particularly attractive or as an inducement: a washing machine with many features. With a more appropriate one: A prominent or distinctive aspect, quality, or characteristic: a feature of one's personality; a feature of the landscape. ... and of course it is undocumented or the software vendor would have removed the feature before shipping the product. All definitions blatantly stolen from http://dictionary.reference.com/search?q=feature
Those are nice definitions, but that's not the definition the author used.. when you bring in the next sentence, it all becomes clear:
"First, let's define zero-day exploit. An exploit is a method devised to take advantage of a specific software vulnerability using a software virus, Trojan horse or worm. When the exploit is done without a virus, Trojan or worm, it's using an undocumented feature. The zero-day type of exploit is discovered, not as part of the security research process, but when an active exploit is using a vulnerability the software developer was previously unaware of."
An "undocumented feature.. the software developer was previously unaware of" is a bug.
Anything that happens that the developer has NOT accounted for, is a bug.
I used to play Ultima 4 on my Apple ][e. I discovered I could 'land' the balloon right next to the Stygian Abyss by saving the game as I floated past the enterance. For me it was a feature, but in reality - it was a bug.

--
"I can't give you a brain, so I'll give you a diploma" - The Great Oz (blatently stolen sig)
Re:LMAO! by frogsarefriendly · 2004-04-13 09:15 · Score: 0

That undocumented permanent login/password backdoor was a feature and you're lucky we didn't charge extra for it! --Cisco
Re:LMAO! by devobelisk · 2004-04-15 07:44 · Score: 1

oooh sorry i didn't use the word bug. again u connoted the meaning of feature to be a positive thing when in fact it is not. a feature is just part of the landscape. for you that feature was a boon, for the developer that feature was a bug.
Re:LMAO! by grupo-xenon · 2004-04-23 22:27 · Score: 1

Most people here didn't read the article. I worte it. There is at least one statement in the article where my tongue was firmly planted in my cheek. Changes by the editor made it into a nonsense statement. As printed: When the exploit is done without a virus, Trojan or worm, it's using an undocumented feature. Original: When the exploit is done without a virus, Trojan or worm, it's called "using an undocumented feature."
Again: Read the original version -- IT WAS A JOKE....

Speaking of astroturf by October_30th · 2004-04-13 07:37 · Score: 2, Interesting

every week there's a few stories about a new MS hole

As opposed to the endless list of problems with free software?

--
The owls are not what they seem

Re:Speaking of astroturf by Atzanteol · 2004-04-13 07:45 · Score: 3, Insightful

...that's being exploited but that they refuse to (or cannot) fix.

Let's get the *whole* quote shall we?

--
"Ignorance more frequently begets confidence than does knowledge"

- Charles Darwin
Re:Speaking of astroturf by October_30th · 2004-04-13 07:55 · Score: 1

that's being exploited but that they refuse to (or cannot) fix
So if some people have figured out an exploit in software and are exploiting it, then revealing it to the whole world is a... service?
That's twisted.

--
The owls are not what they seem
Re:Speaking of astroturf by the_mad_poster · 2004-04-13 08:16 · Score: 2, Interesting

Ah yes. The old "Let's compare the security of programs that Microsoft makes against every hackjob program out there under the GPL or BSD license that might be exploited across a good dozen distributions."

While we're at it, lets fail to consider that there's no such thing as an exploit-free system that still does something useful, and let's not consider the other critical part of security: response and patch times.

In other news, there are a lot more apples in the world than oranges when you compare every apple in the world against the oranges in Utah.

--
Alito: A vote for Alito is a punch in the eye to put that bitch back in her place!
Re:Speaking of astroturf by Anonymous Coward · 2004-04-13 08:20 · Score: 0

Yes, it's a service. If the exploit is on port 443 and no patch is available and it's actively being exploited, people can protect themselves by blocking port 443.

If you buy a product from a software vendor, and you lose data/time/whatever due to security vulnerabilities in that software, AND the vendor knew about it, AND they didn't tell you about it, AND you could have minimized your risk if you HAD known, you have every right to be pissed at the software vendor.

What's twisted is vendors keeping secrets from their customers about product safety issues. Ford couldn't get away with it, why does Microsoft?
Re:Speaking of astroturf by October_30th · 2004-04-13 08:24 · Score: 1

Yes, it's a service. If the exploit is on port 443 and no patch is available and it's actively being exploited, people can protect themselves by blocking port 443.
So instead of a limited group of professional people exploiting the security hole we invite the whole world to join the party?

--
The owls are not what they seem
Re:Speaking of astroturf by Fapestniegd · 2004-04-13 08:32 · Score: 2, Informative

So if some people have figured out an exploit in software and are exploiting it, then revealing it to the whole world is a... service?

Yes, it allows me to turn the software off, or take the machines down running it until I can patch it. Keeping me in the dark is doing me a disservice.
That fact that a good deal of people are not vigilant about security and let their machines get exploited is no reason those of us who are vigilant should be penalized.

And I realize that 24 hours is not a lot of time to install a patch, but If you're serious about security, you stay up all night applying them if need be, and have vulnerability alerts going to a pager or cell phone. I don't understand how keeping it a secret and leaving people vunerable is better than allowing them to take *any* action to fix it.

You don't have to wait for the patch to shut down a service, or switch off a feature. As far as I'm concerned there should be a preliminary warning the moment the vendor is aware of an expliotable service, and a patch made available ASAP. Then people paying attention can get on with their day, and those who aren't can get hit when the worm comes out (after the patch is released)
Re:Speaking of astroturf by Fapestniegd · 2004-04-13 08:36 · Score: 1

So instead of a limited group of professional people exploiting the security hole we invite the whole world to join the party?

If people are turning off/blocking the service, where is the party? No service, no exploit, get it?

Oh, you're refering to the people doing a half-ass job at protecting their networks, Yeah they will be having some fun playing catch-up.
Re:Speaking of astroturf by Anonymous Coward · 2004-04-13 08:36 · Score: 1, Insightful

We invite the whole world to protect themselves. The flaw in your argument is that "the whole world" is not comprised of hackers. Nearly all of "the whole world" has a right to defend itself against a small minority of hackers, don't they? Exactly who does keeping things secret protect? Not the users, because it's an active exploit. Not the hackers. No, keeping secrets protects nobody--except for protecting software vendors from being held to any standards of accountability.
Re:Speaking of astroturf by October_30th · 2004-04-13 08:39 · Score: 1

I don't understand how keeping it a secret and leaving people vunerable is better than allowing them to take *any* action to fix it.
Isn't it obvious?
Like it or not, most people won't install a quick fix for a security hole even if it was available from day 1. Therefore, the less people know about the exploit, the less abuse there will be until a major security upgrade is released.

--
The owls are not what they seem
Re:Speaking of astroturf by October_30th · 2004-04-13 08:42 · Score: 1

Oh, you're refering to the people doing a half-ass job at protecting their networks
Like my grandma who "just wants to read her e-mail and surf the net"?

--
The owls are not what they seem
Re:Speaking of astroturf by October_30th · 2004-04-13 08:44 · Score: 1

Exactly who does keeping things secret protect? Not the users, because it's an active exploit.
Actually it does protect users because keeping the exploits secret limits the number of hackers. There will always be exploits, therefore the only way to defend oneself is to limit the access to the information about exploits.

--
The owls are not what they seem
Re:Speaking of astroturf by Fapestniegd · 2004-04-13 09:01 · Score: 3, Insightful

So we leave responsible people in the dark (and at risk) until every last irresponsible person gets a clue. Let's not reduce important work to the lowest common denominator, ok?

I don't care if "most people won't install a quick fix for a security hole even if it was available from day 1," I will, so let me protect my network and let their networks burn.
Because the people you're talking about have shown that they will not install a patch *months* after "a major security upgrade is released," so how does this security model help at all? Hell most of them aren't even aware of the vulnerability untill their machines slow to a crawl and they hear about a new worm on the local news. So why should I wait for them to patch before I protect myself?
Re:Speaking of astroturf by October_30th · 2004-04-13 09:06 · Score: 1

Let's not reduce important work to the lowest common denominator, ok?
On the contrary, let's reduce it to the lowest common denominator.
Why? Because sooner or later (if not already) most computers on the net will be run by the "lowest common denominator" people and not by elite like you.
Heck, even I don't upgrade my WinXP at home until the automatic upgrade thingy tells me to. I don't have the time or the will to follow some security mailing-lists.

--
The owls are not what they seem
Re:Speaking of astroturf by Fapestniegd · 2004-04-13 09:06 · Score: 1

Like my grandma who "just wants to read her e-mail and surf the net"?

It the shoe fits...
I'm not trying to insult your grandmother here, but it seems to me you want me to wait for her to get up to speed on network security before *I* can defend myself against potential worms. That's absolutely insane. I would be more inclined to agree to take her computer away until she learned how to operate it. But I'm not even close to agreeing to that.
Re:Speaking of astroturf by October_30th · 2004-04-13 09:10 · Score: 1

*I* can defend myself against potential worms. That's absolutely insane.
Huh? Did I miss something here?
You CAN defend yourself against potential worms by keeping the friggin' exploits in the dark!

--
The owls are not what they seem
Re:Speaking of astroturf by Fapestniegd · 2004-04-13 09:14 · Score: 1

Because sooner or later (if not already) most computers on the net will be run by the "lowest common denominator" people and not by elite like you.

But the data these people are protecting isn't (comparatively) important. So the people at the CDC in Atlanta should leave biological agent threats vulnerable, until the lowest common denominator "gets it"

There is a great deal of important information in play here. If the lowest common denominator has to put up with worms to protect it, I can live with that. I cannot live with dangerous information becoming public so 3rd graders can usr their 'puter to chat about whatever it is third graders chat about.
Re:Speaking of astroturf by October_30th · 2004-04-13 09:16 · Score: 1

Computers storing dangerous information (CDC) have not place to be on the net in the first place.

--
The owls are not what they seem
Re:Speaking of astroturf by MachineShedFred · 2004-04-13 09:20 · Score: 1

However, you're single WinXP box at home is not costing thousands of dollars for every minute that it is down due to the latest virus parading around the Internet.

That is the situation lots of people that post here deal with, myself included. Sure it is great to have "security through obscurity" but if you lose that safety blanket of obscurity, you are bleeding money from systems that have to be operational for business to continue.

This is no different that having RAID 5 arrays for data redundancy, hot-swappable power supplies, and fail-over network links. If you have to be up, you do the due diligence to make it happen.

I guess what I'm saying here is that vendors withholding information about exploits and bugs makes for an inherently unuseable platform for highly available systems. These highly available systems are also the ones that have people that are PAID to have the time [or] the will to follow some security mailing-lists.

--
Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
Re:Speaking of astroturf by Fapestniegd · 2004-04-13 09:28 · Score: 1

Your conclusion has the following implied premise:
"All worms are released after the exploit is made public"

This premise is false. If an exploit exists, a worm can be written. It does not need public exposure be so.

Keeping exploits in the dark only raises the bar on who can write them. This means a secret exploit can be used by professional hackers to gain access to "secure" networks and do really bad things, like steal data, until I am notified and can turn the service off. By making the exploit public, you can eliminate the threat of the professional hackers as well as the threat of the reverse-engineering hackers. But the worm comes out in a day and mucks with networks that are not being managed properly.

If you think there are not professional level system crackers with unknown exploits stealing data right now, you need to study security history some.

I believe we differ on this point. I want to keep my networks and data secure, and you want to keep worms from effecting the general population. While I understand worms are annoying, they are so annoying as to leave critical systems (air traffic control systems come to mind) vulnerable to prevent them.
Re:Speaking of astroturf by Fapestniegd · 2004-04-13 09:34 · Score: 1

Uh, "the net" started out as the ARPANET created by the Department of Defence. When "the net" started, it *ONLY* had dangerous information on it (military stuff and the like) so the people checking their email and shopping on ebay are the newcomers here.

But I guess we should force all of the CDC and DoD off of the net until Windows XP users can get thier act together? Right?

Yeah, that will happen.
Re:Speaking of astroturf by October_30th · 2004-04-13 09:34 · Score: 1

"All worms are released after the exploit is made public"
No it's not.
I'm just accepting the limited number of crackers using the exploit as a lesser evil. Making the exploit public and hoping that the public will fix the hole is a pipe-dream and results in a disaster.

--
The owls are not what they seem
Re:Speaking of astroturf by October_30th · 2004-04-13 09:38 · Score: 1

But I guess we should force all of the CDC and DoD off of the net until Windows XP users can get thier act together? Right?
Uh... do you really thing that CDC, CIA, FBI, DoD or any other similar organization has any of their sensitive information on computers that are connected to the net?
I'm sure someone can back me up on this, but I don't think so.
So yes, CDC and DoD have already been "forced" off the net.

--
The owls are not what they seem
Re:Speaking of astroturf by Fapestniegd · 2004-04-13 09:40 · Score: 1

I'm just accepting the limited number of crackers using the exploit as a lesser evil

How many crackers do you think it takes to write a self-replicating and self propagating worm?
The answer is one, not "a limited number" plus one.
Re:Speaking of astroturf by October_30th · 2004-04-13 09:44 · Score: 1

Ok, and why has this apocalyptic worm not surfaced already?

--
The owls are not what they seem
Re:Speaking of astroturf by Fapestniegd · 2004-04-13 09:48 · Score: 1

Uh... do you really thing that CDC, CIA, FBI, DoD or any other similar organization has any of their sensitive information on computers that are connected to the net?

Yes they do. Do you honestly belive these organizations do not use the internet backbone to share data, Do you think they use the pony express or something? Or do they just not talk to each other? Or do they use some other internet? Because they don't. They use the same infastructure we (general population does) their networks have better security as a rule, but there on here with us.

The parent post is absolutely unbelieveable in it's naivete.
Re:Speaking of astroturf by Fapestniegd · 2004-04-13 10:01 · Score: 1

Oh my God, Are you saying that if something hasn't hapened yet, then it can't happen? That's some great logic buddy.

The reason professional system hackers do not release malicious worms is because they are to busy stealing data and selling it. Writing a worm would let people know about the exploit (which, for a time, only they have knowledge) so I guess you would let them continue to exploit systems indefinately. Worms are not the worst thing that can come from an exploit. But you seem to think they are.

Remind me to NEVER hire you in a security role.
Re:Speaking of astroturf by Anonymous Coward · 2004-04-13 10:53 · Score: 0

...because one hacker, armed with the knowledge of an unpatched exploit, can only attack a limited number of machines? Exactly what is the upper limit on the amount of computers a single hacker can compromise? I'd love to hear it.
Re:Speaking of astroturf by Aoreias · 2004-04-13 10:59 · Score: 1

"I will, so let me protect my network and let their networks burn."

Just don't be surprised when their networks DDOS your networks.

--
We've upped our standards. Up yours.
Re:Speaking of astroturf by blueskies · 2004-04-13 13:45 · Score: 1

Just don't be surprised when their networks DDOS your networks.
Well, i'd rather be secure but DoSed. Would you rather have your financial information harvested off your computer than have your internet link go down?

Do it right the first time... by Banner · 2004-04-13 07:37 · Score: 2, Insightful

And you won't have to keep patching it, would you? Of course that would mean spending money and time up front, rather than being able to hide the costs of the continuous maintenance cycles.

It would also mean forcing more programers to do their jobs right, and more managers to learn what they're doing as well (And that code doesn't fix itself because you lit a candle for it the night before).

Re:Do it right the first time... by PoesRaven · 2004-04-13 07:48 · Score: 2, Insightful

sorry, but your obviously NOT a programmer
no matter what you do, your code will have bugs.
you just do everything you can to keep them to a minimum, but if you spent a hundred years working on the same project, when all was said and done there would still be bugs.
Re:Do it right the first time... by negacao · 2004-04-13 07:50 · Score: 4, Insightful

It would also mean forcing more programers to do their jobs right,

Maybe if we were given some fucking time to do the job right......
Re:Do it right the first time... by MrRuslan · 2004-04-13 07:50 · Score: 1

To do it right the first time dosent always work...we are people...people make mistakes...when we write code it shows...there should be turogh testing and quality control but nothing is pefect..and i belive that a patch should be issued asap and a patch version of the software in question avalable from the distributer of the app in question...the Open source model is a very good example.
Re:Do it right the first time... by Banner · 2004-04-13 07:55 · Score: 1

I'm sorry, but no, you're wrong. It is totally possible to release code without serious bugs.

I started programing in the early 70s, where you even alive then? So please don't say I'm not a programmer. I just know HOW to do the job right.
Re:Do it right the first time... by Banner · 2004-04-13 07:57 · Score: 1

That's why the managers have to learn how to do -their- jobs right as well. Too many managers don't understand software or the software coding process. So they make unrealistic demands.
Re:Do it right the first time... by PoesRaven · 2004-04-13 07:59 · Score: 2, Interesting

and im telling you your crazy the highest levels of software quality control are in terms of bugs per so many lines even important life critical software used by the military and government institutions has bugs -- 1 bug per many thousands of lines, after spending millions of dollars auditing it you can keep bugs to a minimum, but you cant get rid of them from any project of real size
Re:Do it right the first time... by Mateito · 2004-04-13 07:59 · Score: 2, Interesting

> no matter what you do, your code will have bugs.

True, but there are steps you can take to minimize bugs. There are ways to check programs for out-of-bounds conditions. There are ways of fixing exploits relatively quickly. (And I mean weeks instead of months). There are ways of releasing "work arounds" instead of fixes.

True, the above may no produce the fastest code, but shit.. we are talking about Windows here. You want it to run faster? Buy a bigger computer.

--
Norman Cook's Ode to Sl
Re:Do it right the first time... by cavebear42 · 2004-04-13 08:06 · Score: 1

I would have to agree with the parent. Bugs happen, thats life. You wouldn't be competative if you put off release until perfect (which would come eventully but not in a timly manner.)

OTOH, It is also true that I dont have a rune blade and therefore there are somethings I can't do so I might have to give it to the grandparent, the writer of perfect code.
Re:Do it right the first time... by Banner · 2004-04-13 08:07 · Score: 1

Have you ever written military software? I have. Funny how those nukes don't go off by accident isn't it? Or all those planes don't suddenly crash because of a software failure.

Look, you're the one who isn't really a programmer. You're just some kid who hacks on computers and thinks he knows how to write code. Serious bugs can be prevented if you just want to make the effort. Problem is most people either don't want to spend that money, or make that effort.

But it can be done, and is done all the time in some industries.
Re:Do it right the first time... by Anonymous Coward · 2004-04-13 08:09 · Score: 2, Insightful

[Do it right the first time] And you won't have to keep patching it, would you?

Ever fail to notice part of some instructions, only to regret it later? Ever use the wrong [software] tool for the job because you couldn't afford the right one? Ever zone out or get distracted during a class/meeting? Ever make a coding error that the compiler didn't catch? Ever shortcut a process because you had to rush home to take care of a sick kid or to meet a "drop-dead" deadline? Regular people do this and programmers are just regular people; they make mistakes. That includes people like Linus Torvalds, RMS, and Larry Wall.

Putting together multi-MLOC software is a dammed tricky process, and saying "Don't make any mistakes" is just plain useless.
Re:Do it right the first time... by Anonymous Coward · 2004-04-13 08:13 · Score: 0

How did the discussion change from "all bugs can be eliminated" to "serious bugs can be eliminated"? I disagree with the first, but agree with the second completely.
Re:Do it right the first time... by PoesRaven · 2004-04-13 08:16 · Score: 1

sorry, but i happen to know what i'm talking about life critical applications do undergo extreme levels of testing and evaluation for bugs, but they dont fix EVERYTHING you cannot fix EVERYTHING -- i agree that you can prevent most major problems, but there are still bugs look up sometime the standards to which life critical code is held, and youll notice that it doesnt refer to software being absolutely bug free -- it refers to the software as having a small bug to line ratio and i resent your attitude -- im not 'some kid' (and that whole insult is flawed, many 'kids' are great programmers) -- i happen to work for NASA
Re:Do it right the first time... by CaptKilljoy · 2004-04-13 08:22 · Score: 1

I'm sorry, but no, you're wrong. It is totally possible to release code without serious bugs.

Sure it is, with proper planning, scheduling, and a skilled programming and QA team familiar with the problem domain.

While I'm in fantasy-land, I'd like a unicorn too.
Re:Do it right the first time... by VAXGeek · 2004-04-13 08:37 · Score: 1

"-- i happen to work for NASA"

You had me until you got to that part. You'd be lucky to get a job at K-Mart. What division of NASA do you work in again? Oh yeah, the IMAGINARY one.

--
this sig limit is too small to put anything good h
Re:Do it right the first time... by lynx_user_abroad · 2004-04-13 08:40 · Score: 3, Insightful

It would also mean forcing more programers to do their jobs right...

Once you get beyond trivial programs, there's no such thing as fault-free software.
The reason for this is that software does not exist in a vacuum; the "correctness" of the behavior of any software is always evaluated through the eyes of the person using it.
This is why software which is considered bug-free today can become bug-ridden tomorrow if an exploit is discovered which exposes some previously hidden undesirable behavior. The software has not changed, but our expectations have changed.
Programmers cannot be expected to know what our expectations will become tomorrow. They cannot even be expected to fully understand our expectations today. That is why so much effort is put into understanding and defining the requirements. It is why very complex software (of the multi-billion-dollar government-contract type) often fails before delivery. It's why the 1.0 version is often considered more "buggy" than subsequent versions (where the users have a better understanding of how it's "supposed" to work).
It's also why two different people can have differing views of the "bugginess" of the same software; each has different expectations and exercises differing features.
And they say you can't test quality into software. Bollocks! Testing is the only way to get quality into software, because only the user can decide what quality means.
And, if you'll forgive the rant, it's why Microsoft hasn't got a prayer against FOSS. The beauty of Free/Open Source Software is that each user can correct the behavior of the software to fit their own definition of bug free. And each user test it themself. If the behavior isn't what they wanted, they fix it themself, ask the developer to fix it, or move on to something else.
Currently, we live in a world where Microsoft gets to define what the correct behavior of software is. If you don't like it, tough. But the world is quickly becomming more educated about what software is capable of, and more people are demanding that their computers adapt, rather than accepting that they must adapt to their computers.
Microsoft tried to define executable attachments as acceptable, then had to redefine that behavior as the filter through which we use Microsoft's software (not the software itself) changed. Windows 95(unpatched) today runs just like it did back in the middle of last decade, but no one would consider it a functional piece of software today.
In a way, Microsoft's operating systems are more buggy than anything else simply because there are more people making up their minds about wether it works the way they think it should work.
And, as the article points out, announcing patches for certain behaviors only highlights the fact that a significant number of their customers believe the original behavior is wrong ( == exploitable).
Do you want to do something real to stick it to Microsoft? Go Educate Somebody.

--
The thing about things we don't know is we often don't know we don't know them.
Re:Do it right the first time... by Minna+Kirai · 2004-04-13 09:10 · Score: 2, Interesting

Have you ever written military software? I have.

So have I. And while I agree that it's theoretically possible to write bug-free software (for a sufficiently small program), even sky-high military budgets can't afford that level of redundant effort. (By quantum physics, nothing is truely impossible. But some things are hard enough to be practically impossible)

The V-22? Lethal software bugs. The FA-22? Software crash every 2 hours.

Funny how those nukes don't go off by accident isn't it?

Just because you haven't observed any catastrophic bugs is no proof that bugs don't exist.

Serious bugs can be prevented if you just want to make the effort.

If you're now talking about "serious bugs" instead of "bugs" in general, then you've backed away from the stronger assertions made earlier.

But it can be done, and is done all the time in some industries.

Which industries, exactly? Aerospace and military software certainly isn't bug-free! They often try, but even they make publicized mistakes (and the majority of bugs found post-fielding are kept quiet for security).
Re:Do it right the first time... by Minna+Kirai · 2004-04-13 09:14 · Score: 1

You'd be lucky to get a job at K-Mart. What division of NASA do you work in again?

I've faced some ex-NASA programmers who were interviewing for work, and have been strenuously unimpressed. The space agency prefers quantity as well as quality, so they hire tons of below-average software engineers.

Note that NASA's software is mostly not written by actual government employees, but by contractors from either Lockheed or Boeing. Google can find you multiple funny stories about the software flaws those guys have launched into space (the crashed and failing Mars probes are only some of them)
Re:Do it right the first time... by PoesRaven · 2004-04-13 09:41 · Score: 1

actually, this in some ways proves my point -- NASA spends a tremendous amount of money and manhours trying to make software as bug-free as possible, but its still very buggy and come on -- NASA coders aren't that bad -- a few small mistakes are never forgotten because of how highly publicised they are. NASA really doesnt have that big of a budget compared to some government groups, but is held to a higher standard of quality, and so appears to be vastly inferior
Re:Do it right the first time... by Theatetus · 2004-04-13 09:55 · Score: 1

Don't forget your unicorn insurance...

--
All's true that is mistrusted
Re:Do it right the first time... by Tet · 2004-04-13 09:56 · Score: 1

no matter what you do, your code will have bugs.
Nope, not true. You can write software without bugs, but it's not usually economically viable to do so. Using formal proofs with something like Z will get you software that works exactly as you intended[1] (i.e., without bugs). But that comes at a price. Jonathan Bowen gives a 5 fold decrease in productivity for using formal methods for development over standard development methods. For most applications, that's not an attractive tradeoff, and you're better off just living with the relatively few bugs that traditional software development yields. Remember, worse is better. But for certain applications, it's worthwhile. Space exploration should fall into that category, for example, due to the huge costs of losing a spacecraft. But even there, budget cutbacks mean that managers are increasingly looking for short term cost savings (e.g., development costs) without considering the bigger picture.
[1] Of course, that assumes that you get your specification right to start with...

--
"The invisible and the non-existent look very much alike." -- Delos B. McKown

Odd... by AsimovBesterClarke · 2004-04-13 07:38 · Score: 1

Some years ago I worked with a group of people who came out of Cray Research (yeah, yeah, I know, I saw the earlier post). Seems one day a manager pulls all the hard drive vendors into a big meeting and tells them "they needed to slow down with all these big drives [1] its impossible to keep the inventory lists up to date."

[1] Not sure, but I'm guessing these would be on the order of 100s of megabytes......

--
Ads are broken.

Patch release cycle by Ckwop · 2004-04-13 07:38 · Score: 5, Insightful

The problem with slowing down that patch release cycle is the software vendors get lazy. "I wont release this patch for 18 months because no-one knows the vulnerability"..

It's a difficult one. On the one hand you've got the problem of lazy vendors and on the other you've got full disclosure where the enemy will like develop the worm before you can test your patch properly.

I think the people that find these vulnerabilities should but an expire date on their vulnerability at which point full disclosure kicks in. There should be protections in law to ensure this practice is legal too.

That way.. we have motivated vendors and give the vendors enough time to fix the problem.

Simon.

Re:Patch release cycle by cavebear42 · 2004-04-13 07:55 · Score: 1

I think the people that find these vulnerabilities should but an expire date
most of them do.
the article was saying that we should think of a way to create simulntainous deploys and such to speed the release of pacthes at a certain release day. (and giving a resonable way to do so.) This is a different plan but about as effective as the way that norton live update works. This is not the same as just procrastinating a release. It is just not a rush to release, hope people are patching right now, sort of approch.
Re:Patch release cycle by sadomikeyism · 2004-04-13 09:10 · Score: 1

The point of developers holding off on releasing patches that are not currently being exploited is PR: If an exploit occurs, you get to immediately whip out the proper patch developed months ago to 'prove' to your customer base that you are very responsive to their needs, and 'obviously' responsive in a way that those evil open source ninnies could never do without a profit incentive... blah blah blah...

--
"Necessity is the plea for every infringement of human freedom. It is the argument of tyrants; it is the creed of slaves

Wouldn't be a bad thing by The+Desert+Palooka · 2004-04-13 07:38 · Score: 5, Interesting

Besides absolutely critical patches (for worms, and exploits in the wild and the like) I think this could be a really good thing. I know when I was a network administrator it was nigh impossible to keep up with all the patches on my linux boxen. If all patches were released like movies and music, on Tuesdays only. It would have been easier. Come into work every tuesday read what patches I need to install...

Either that or like one poster suggested, we just need better tools for keeping track and managing the flow of updates... Strangely enough, MS's XP update does a really good job at this (despite their slow release process).

Re:Wouldn't be a bad thing by Banner · 2004-04-13 07:43 · Score: 1

I have to agree that for people in your position regular release schedules for patches and the like are probably a great idea.
Re:Wouldn't be a bad thing by grasshoppa · 2004-04-13 07:45 · Score: 2, Insightful

Sorry, I'm going to go with a WTF here. Windows is, far and away, the harder system to keep up to date, and it's dead easy to do now ( so no excuse to those of you window admins that don't keep your systems patched daily ).

Depending on the distro, Linux is mindlessly easy to keep up to date. Of course, you wouldn't use slack in this sort of enviroment, but RH has a nice package management system, and let us not forget Debian.

Cron jobs, that's where it's at.

--
Mod me down with all of your hatred and your journey towards the dark side will be complete!
Re:Wouldn't be a bad thing by Rikus · 2004-04-13 07:50 · Score: 1

> If all patches were released like movies and music, on Tuesdays only...

That's great, but it doesn't change the fact that the issue is still there (as it had already been until discovered), and the numebr one priority for many people is minimizing the window of time that their XYZ is vulnerable to ZYX. I'm sure there are many people who would say "Screw convenience. If there's a problem, I want to know of it and fix it ASAP".
This seems to fall under the category of "temporary security through obscurity" or "security through convenience".
Re:Wouldn't be a bad thing by Gr33nNight · 2004-04-13 07:52 · Score: 1

Its not just the OS that is the problem. I am a Windows/Novell admin, and OS updates are not a problem (SUS). The problem lies in all the applications that need to be patches. Here is a short list :

AutoCAD 2004 (regular and LT)
Voloview 3.0
Office XP (plus Visio 2003, Publisher 2000, etc - my boss rocks!)
Pro/Engineer
etc etc etc.

It would be a huge timesaver if there was 1 server application that could manage all the patches for all the applications that I have to support. Thats where I spend the most time, testing various patches and throwing them down thru Zen.
Re:Wouldn't be a bad thing by Rikus · 2004-04-13 08:06 · Score: 1

Instead of having to patch all these things right away, or having to have the information hidden from the public until the convenient "mass-patch date", why not allow the same people who release patches to release security advisories with verbose and advanced severity ratings which could be used to temporarily bring the vulnerable component down until a patch could be applied? This would obviously not be acceptable for high-traffic servers, but if things were designed with greater modularity, less-used components could be automatically disabled by these up-to-the-hour advisories, without having a fix pushed onto the system. The admins would be notified by email of the problem and would be able to patch the system and re-enable the disabled/vulnerable as soon as they got the message.
Re:Wouldn't be a bad thing by Anonymous Coward · 2004-04-13 09:58 · Score: 0

Besides absolutely critical patches (for worms, and exploits in the wild and the like) I think this could be a really good thing. I know when I was a network administrator it was nigh impossible to keep up with all the patches on my linux boxen.

I'm not sure when you were a Linux Admin, but this stuff is pretty much not an issue nowdays provided you know what your doing and are smart enough to get the right distro. Back when I used RedHat 7.0 release to the EOL on 7.3 up2date did the updates for me. The RHN gives you an email about the vulerability, and you can schedule updates on the web with a few clicks, or just run up2date -u and let it go.

Since then I've moved to FreeBSD. The ports tree syncs everynight and Portupgrade downloads all the source files to be updated, then a simple shell script emails me what is out of date. I make some packages, test them and the other servers can pick them up and install them. Just subscribe to the Security Updates and it's basically the same thing but more managable.

The problem with Windows update is that it tracks some things, but not others. You would THINK that it would be smart enough to detect you're running an exchange server and check for updates, but you are expected to track that yourself.
Re:Wouldn't be a bad thing by Jadrano · 2004-04-13 10:54 · Score: 1

Either that or like one poster suggested, we just need better tools for keeping track and managing the flow of updates... Strangely enough, MS's XP update does a really good job at this (despite their slow release process).

Indeed, I think MS's XP update is relatively good, in particular when it comes to get private users who do not really care about patches to install them.
Such easy installation of security patches is available for Linux, as well. For instance, SuSE's YOU (Yast Online Update) works about the same way, and I find it even easier to customize than XP update. By default, a red button in the taskbar shows that there are new security updates for installed software (which can be downloaded and installed with the root password and a few clicks), if it's green everything is up to date; YOU can also be set to install security patches automatically.

They got their myth wrong by Anonymous Coward · 2004-04-13 07:38 · Score: 0

One "myth" was that software vendors need to speed up their patching processes.

Actually, even if I do for the sake of argument grant for the moment that it is a myth, I believe only one vendor is being asked to speed up the process. The others are either doing fine, or face normal market pressures that will punish them for not doing fine.

And it's not a myth.

Perhaps the article should be titled "Forcing software vendors to act responsibly could destroy civilization!"

But then how can vendors be 1337? by Rex+Code · 2004-04-13 07:38 · Score: 4, Insightful

The problem is that the standard for what constitutes a security hole has become (in some cases) ridiculously low. A few years ago, you'd have to have a demonstratable exploit to get a vendors attention. These days, someone notices an overflow, or an off-by-one error in the source code, and makes a post to full-disclosure or BugTraq, and next thing you know all the vendors have to patch it even if it doesn't pan out to have real security implications. On top of this, you've got the vendors themselves issuing advisories for low-level risk issues which forces the other vendors to issue advisories themselves.

After crying wolf so many times, it's no wonder advisories concerning critical security holes can get lost in the shuffle.

Re:But then how can vendors be 1337? by ciroknight · 2004-04-13 08:01 · Score: 1

someone notices an overflow, or an off-by-one error in the source code, and makes a post to full-disclosure or BugTraq

In other words, putting the opposite spin on what you're saying of course, is that Open Source breeds more perfect software right? Not just more secure, but little bugs like this are fixed, which can lead to big issues down the road, right?

I can see what the article's saying, but at the same time, things that are very critical should be patched right away, and the patch should be applied by everyone right away. Minor things should be bunched collectively and released at one big patch. This is actually why I believe the old Service Pact archetecture worked better than patch patch patch patch, etc....

Either way, commercially developed programs have to be reverse engineeered to find security problems, and often, commercial patches have to be reverse engineered to find the same problem. Open Source allows anyone to fix the problem, before it becomes a bigger one. Can't think like a republican (~only the "now" matters~) on these things.

--
"Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is." G.W.Bush
Re:But then how can vendors be 1337? by tomhudson · 2004-04-13 08:12 · Score: 1, Informative

There's one point that has been missed so far ... here's the quote from the article:
They know there is a much easier way to determine the details of a particular vulnerability than slogging through millions of lines of assembly.

It's not possible to slog through millions of lines of assembly. Even if you do 1 line a second, 8 hours a day, 5 days a week, you won't finish in less than a few months (of course, if you have a 10-million-line source code program, the binary will hold a LOT more than "a few million lines of assembler"). You won't finish within your working lifetime.
By then you're out of date anyway.
Guess we can score 1 more argument for open source.

Quality not quantity by SkiddyRowe · 2004-04-13 07:39 · Score: 4, Insightful

Personally I'd rather see patches that won't open new vulnerabilities. Too many times we've seen these quick reflex fixes from Redmond, only to see that they release a patch for the patch. I'd rather patch the problem fully, than have a quick punch patch, that just gets exploited a week later.

fuzzy logic? by Zoko+Siman · 2004-04-13 07:39 · Score: 3, Insightful

I don't see how this really changes anything. Either way, once the patch is released from what this guy is saying is that an exploit will come out in not much time. He's basically just saying to release the patch at a later date, I don't see any real reason however to justify his reasoning. How do you expect to get the problem patched at all if you just don't release the patch? To me to seems like with this reasoning the man is using we could just forever delay all patches.

Re:fuzzy logic? by nahdude812 · 2004-04-13 07:50 · Score: 1

Although I don't agree with the article's author, I think the inference is that if patches were released more like service packs, where you patch 30 or 40 things at a shot, and only have to do it once a month, that the lower administrative overhead involved in this model (vs the micro patching from today) would encourage a shorter average time from patch release to patch install across the board.

--
Slay a dragon... over lunch!
Re:fuzzy logic? by devobelisk · 2004-04-13 08:01 · Score: 1

you obviously missed the point. he is suggesting developing better patching systems so that all systems get updated SIMULTANEOUSLY. taking the responsibility off from lazy admins, or in my experience, no admin at all.
Re:fuzzy logic? by Zoko+Siman · 2004-04-13 08:02 · Score: 1

Now that I could understand. Perhaps a monthly recap or something. That makes more sence them just 'delaying them.' Which is what he seemed to be getting at.
Re:fuzzy logic? by Bozdune · 2004-04-13 08:07 · Score: 1

Nice point, what was the vendor supposed to do? Invite all their customers to a secret club meeting where the club handshake and the club password is needed to get in the door, and the patch is handed out by invitation only?

I guess another plan would have been to disguise the patch inside an "update" that modified a lot of the rest of the code, making it harder for the script kiddies to latch onto the key changes.

Maybe we are heading toward an era in which patches are issued in encrypted form, and special top secret super duper decrypto modules are the only mechanisms that can unpack and install the patch. Still would have to change a lot of unrelated stuff, though, because the crackers will have dumped core previously in preparation for a diff.
Re:fuzzy logic? by nahdude812 · 2004-04-13 08:36 · Score: 1

The problem is that this necessitates a larger average time between vulnerability discovery and vulnerability fix. The author defines zero-day exploits but doesn't address the fact that his proposed model seriously increases the exposure surface area to these aside from to make the insubstantiated claim to the effect of "these don't really exist".

--
Slay a dragon... over lunch!
Re:fuzzy logic? by djm2cmu · 2004-04-13 09:36 · Score: 1

Try reading the article all the way to the end next time...

In one possible scenario, software owners would subscribe to an automated patch service. Those without a subscription would receive the patch through current means, but it would expose those users to greater risk. Subscribers would receive a predeployed, encrypted version of the patch. At a predetermined point, a decryption key would be passed to a patch installer on all subscribed systems. Since the size of the key is small compared to the patch itself, the key distribution could be considered nearly instantaneous, and all affected systems would have the patch installed simultaneously with the official release of the patch. By the time the code exploiter even begins to reverse-engineer the patch, most affected systems would be immune.
It's an interesting thought at the very least.
Re:fuzzy logic? by Bozdune · 2004-04-13 10:38 · Score: 1

I did, and still missed it. Sigh. Must be age.

I never update by Anonymous Coward · 2004-04-13 07:40 · Score: 2, Funny

I never update and I don't have any problems.

Never had a virus worm or any of that crap.

What am I doing wrong?

Re:I never update by Banner · 2004-04-13 07:46 · Score: 1

Running Slackware? ;-)
Re:I never update by Anonymous Coward · 2004-04-13 07:49 · Score: 0

You're using *BSD, that's what you're doing wrong. :)
Re:I never update by Skye16 · 2004-04-13 07:55 · Score: 1

Well, you should probably drag your computer back out of that safe you buried under a nuclear power plant. No wonder you're not getting anything.
Re:I never update by Lehk228 · 2004-04-13 08:29 · Score: 2, Insightful

are you behind a NAT/Firewall/Switch, they protect against ***almost*** all remote exploits by making your computer unroutable from the outside "you can't get there from here"

--
Snowden and Manning are heroes.
Re:I never update by morcego · 2004-04-13 08:38 · Score: 1

This looks like a joke, and I'm all for a laught, but it raises an important issue never the less.

Not being aware an compromise is very different than not being compromised.

--
morcego
Re:I never update by Geoffreyerffoeg · 2004-04-13 08:40 · Score: 1

Using a dumb terminal connected to a mainframe.

in related news by jannesha · 2004-04-13 07:41 · Score: 5, Informative

There's new critical updates available on Windows Update (5 in all, for WinXP + IE 6SP1).

Re:in related news by MrRuslan · 2004-04-13 08:00 · Score: 0, Troll

That is not news...thats common knowledge...cmon it's microsoft for god sakes...
Re:in related news by awkScooby · 2004-04-13 09:01 · Score: 1

MS04-11 Windows Local Security Authority Service Remote Buffer Overflow was reported to Microsoft on September 8, 2003 by eEye security.
MS04-12 Microsoft DCOM RPC Memory Leak and Race Condition was reported to Microsoft on September 10, 2003.
There still are 3 remote exploit holes which eEye identified which haven't been fixed. Two were reported 216 days ago, and the other was reported 188 days ago.
I really hope the author of the article isn't saying we should slow down beyond this. How do you know that any of these aren't zero-day exploits? Massive spreading worms are not the only security problem -- there are hackers who can find this stuff.
Pretend for a moment that you are a hacker who finds one of these holes. Do you want to waste the opportunity, giving it away to script kiddies, or use it to backdoor some of those systems you've been dying to get into. Script kiddies are the bane of your existance, because they force people into patching stuff that otherwise would be left wide open for you.
Now take the flip side of this. You're a sysadmin responsible for keeping a hacker like that out. Well, apparently you can't because companies are refusing to patch holes in a timely manner.

Automatic updates by dj245 · 2004-04-13 07:41 · Score: 1

Why is this an issue with automatic updates? Set Granny's computer to be automatically patched whenever available. Don't instruct her to review patches herself by clicking ok, then yes, then scroll down to "I'm really sure I want to patch" and then hit "update". She won't do it, and then later you'll have to fix her computer when her computer gets "owned". If you're paranoid, review each patch on your personal machines individually. But for grandmothers and clueless people everywhere, ignorance really is bliss with the automatic updater. They don't care that that "you have been patched". They don't know what "There are 57 critical updates available" mean and they don't want to learn. Why bother with educating a bunch of monkeys who don't wish to be taught when the software makes it so easy that the monkey doesn't have to know?

--
Even those who arrange and design shrubberies are under considerable economic stress at this period in history.

Re:Automatic updates by simonfairfax · 2004-04-13 08:08 · Score: 1

The Luxury of Ignorance is a good resource for 'granny-proofing' programs.
Re:Automatic updates by Lehk228 · 2004-04-13 08:33 · Score: 1

Put grandma behind a NAT box and periodically stop in and update for stability, I have my parents behind a NAT and they don't have any issues with worms despite never patching when they should

--
Snowden and Manning are heroes.

Zinger by CaptKilljoy · 2004-04-13 07:41 · Score: 2, Insightful

Nice ding against Linux and open source:

"...or allowed critics to claim the superiority of some other system that supposedly doesn't need patches."

He's right though. Just because certain closed source vendors aren't doing so well with bugs, doesn't mean that the open source movement can sit back and laugh at them. There needs to be as much participation as possible to maintain OSS's reputation for quality.

Re:Zinger by Lane.exe · 2004-04-13 08:03 · Score: 1

Which is why most major OSS distributions regularly release patches and updates. Most OSS projects also release bugfixes and patches whenever a problem is discovered. The difference usually is that when an OSS bug is discovered, the world is told about right away, so that if mission-critical systems are exposed, they can be watched constantly or removed from vulnerable networks until the patch is released, which is usually in short supply. Contrast that to closed-source vendors, who may never release the news of the exploit and quietly patch it one day, hoping no one noticed or was compromised in the interval.

--
IAALS.

A perspective from a gentoo user by frodo+from+middle+ea · 2004-04-13 07:41 · Score: 2, Insightful

Every time I do emerge -pUv world, I remember I haven't synced the latest tree. So I do emerge --sync and , then bam, another 200 packages to upgrade.

Some times the changes are so minor, I really wonder if it is worth it.

--
for the last time people, I am "frodo from middle eaRTH", not "middle eaST".

Re:A perspective from a gentoo user by MrRuslan · 2004-04-13 07:56 · Score: 2, Informative

After you run emerge sync you should run emerge -u -p world it will tell you what you can update...u dont have to do evrything...just pick whatever makes sense...no need to update OpenOfiice.org from 1.1 to 1.1.1 ....but if there is something like ssh or postfix its a good idea to grab those...i mean use common sense...and sense u read slashdot you should know of any BIG remote exploits that apear and emerge fixes for them...but if it work for you dont fix it by emerge -u world....simply not neccesary.
Re:A perspective from a gentoo user by frodo+from+middle+ea · 2004-04-13 08:03 · Score: 1

Exactly my point. After a while the emerge -u world becomes unuseable. Everytime I have to emerge -puv world, and then select the one's that I really need to fix and neglect the others.
What portage needs to do , is seperate security fixes from enhancements. of course for major upgrades, security fixes and enhancements will be in the same version. but atleast when going from 0.98_0.1r3 to 0.98_0.2 , I should know if the upgrade was for a secuirity fix or add some eyecandy enhancement, which I can do without.
And reading individual changelogs of each ebuild is not an answer.

--
for the last time people, I am "frodo from middle eaRTH", not "middle eaST".
Re:A perspective from a gentoo user by devobelisk · 2004-04-13 08:04 · Score: 1

no it's not worth it... especially on a slow machine, that sync takes forever.
Re:A perspective from a gentoo user by justMichael · 2004-04-13 08:06 · Score: 1

You need to think a little lazier ;)

Drop this into /etc/cron.weekly
#!/bin/bash emerge -q --nospinner sync emerge -up world
Now if they would only stop releasing borked packages.
Re:A perspective from a gentoo user by justMichael · 2004-04-13 08:09 · Score: 1

Sounds like you want glsa-check.

Not quite perfect yet, but getting closer.
Re:A perspective from a gentoo user by MrRuslan · 2004-04-13 08:13 · Score: 1

well...it is natural for gentoo to be this way...i mean it's not automated...i personally find that a good thing...i guess a seprete flag for emerge to display security fixes and esential bug fixes would not hurt but i personaly can deal without it.
Re:A perspective from a gentoo user by arkhan_jg · 2004-04-13 08:14 · Score: 1

If you only want to regularly check for the important security updates, other than minor bugfixes, feature upgrades etc

there's a new experimental feature, GLSA only updates

Basically, it's a script that only pulls in the updates that warrant a gentoo linux security announcement.

It's still worth doing an emerge -puvD world every so often though ;)

--
Remember kids, it's all fun and games until someone commits wholesale galactic genocide.

How'd that one get past QA? by Anonymous Coward · 2004-04-13 07:42 · Score: 1

If software were to be QA'd properly it might help, it seems a lot of times that testing is thrown to th e wind... let the users be the testers....

Re:How'd that one get past QA? by Banner · 2004-04-13 07:49 · Score: 1

Also don't forget, you can't Test Quality into a product!!! Testing is NOT QA!!!

How does the Kool-aid taste? by Minwee · 2004-04-13 07:43 · Score: 3, Insightful

[...] most importantly, once the patch was released, the exploit was released the very next day. This wasn't a coincidence where the exploiters just missed having a zero-day exploit. If the patch had been released a week earlier, the worm also would have come out a week earlier.

He's arguing that they should slow down the patch cycle because all exploits come from reverse engineering patches. Slow down the patches, and you slow down the exploits.

Because, you know, nobody ever figures these things out on their own. It sure is a good thing we live in a world where exploits are never found in the wild before a nice, safe, 100% effective patch is released to counter them.

Re:How does the Kool-aid taste? by Anonymous Coward · 2004-04-13 08:43 · Score: 0

"He's arguing that they should slow down the patch cycle because all exploits come from reverse engineering patches. Slow down the patches, and you slow down the exploits.

Because, you know, nobody ever figures these things out on their own. It sure is a good thing we live in a world where exploits are never found in the wild before a nice, safe, 100% effective patch is released to counter them."

You're not listening. He said slow down the patch cycle, nt stop it. There's probably an ideal patch frequency that slows down exploits discovered by crackers, and also makes it likely that most systems are patched, preventing reverse engineering of the patch to make the problem worse.

Patches in the near future- by TJ_Phazerhacki · 2004-04-13 07:43 · Score: 2, Interesting

Although I believe it is important to focus more on creating a good product out of the door - Dev's take note, buggy releases are more of a headache to fix than to do it right the first time - I feel that in specific instances - online games, optimized databases, web-related code, it is vital that patches are up to current asap. In a game, a bug will be exploited thousands of times before it can be patched (especially larger MMORPG's), and it is only fair that Mission critical software have the latest fixes (although newer should mean better, not just more complicated!) All I'm saying is that it may not be vital that the latest 10-year-old-driver error fix be released as a complete upgrade, requiring downloading of massive files and lengthy installs. PS - While on the subject, is it that difficult to write programs that only change the affected code? Why must we continue to run complete file changes? A simple program that fixes the code is sufficient, and we get a massive chunck of data, most of which is repetitive. Sorry, some of us have broadband, but some of them don't. And even a couple of megs gets to be a big issue.

--
Physics is nothing like religion. If it was, we'd have an easier time trying to raise money!

Greatest patch of all by cexshun · 2004-04-13 07:43 · Score: 5, Insightful

I think the greatest "fix all" patch would be to distribute a book with every PC sold titled "The Internet: How to not be an idiot". I can't think of many email viruses out there that can exploit the ol' "Do not open unless I know what it is" bug!

Re:Greatest patch of all by xxdinkxx · 2004-04-13 08:01 · Score: 1

I think the greatest "fix all" patch would be to distribute a book with every PC sold titled "The Internet: How to not be an idiot".

I think I smell something.. hmm.. yeah its called a class action suit of users who would claim emotional trauma and argue that they are being assumed stupid. It isn't a bad idea, but you'd have to watch the way things are worded... Also, who reads anymore these days. Now, make it a porn magazine with captions of what to do and not, and then there might be some interest.

Pure insanity but it makes business sense. by Clinoti · 2004-04-13 07:44 · Score: 1

The only comfortable allude I can see to this is the mirror that some companies take to fixing items or training new hires: It is more of a cost benefit to allow the problem or issue to continue than it is to delegate a $100pr hour tech to fix one PC or train one person. They can save more money by having that same $100 per hour tech fix 10 PCs or train 10 people.

The answer is going to come from the market who will decide in MS's case if they do not mind waiting for the plugs to fill the dyke, vs. OSS who have union guys who do nothing but hang around the dyke looking for work.

--

Let's keep in mind that patents are in place to keep lawyers employed and keep them litigating. -CatGrep

Re:Pure insanity but it makes business sense. by Anonymous Coward · 2004-04-13 08:10 · Score: 0

$100 per hour for tech support? Where exactly do you work, and are they hiring?

The article is definitely correct! yay! by heironymouscoward · 2004-04-13 07:45 · Score: 1

Whereas security holes used to be obvious and easy to find, these days they require a lot more work to find.

This is why there are fewer exploits than ever before, and fewer cases of PCs being 0wned and trojaned.

The recent BlackIce break-in clearly demonstrates... oh, sorry, it doesn't, and attacks on PCs are escalating, not going down.

Perhaps professional attackers don't need to wait for exploits after all.

--
Ceci n'est pas une signature

Re:The article is definitely correct! yay! by stevey · 2004-04-13 08:19 · Score: 1

Frankly I cannot believe that exploits are harder to find or write than they used to be.

I've been auditing Debian source code for a few months now and I'm still finding trivial bugs that have security impact.

Sure it's much easier for me to do this as I have the source code available, but I bet that people skilled in assembly language armed with a good decompiler would have a similar score against binary targets.

I've even been writing tools to allow this kind of binary scanning (again for Linux and Debian especially) so it could well be the case that people with little assembly language could be doing it.

Exploits are often hard to detect... by cheezit · 2004-04-13 07:46 · Score: 5, Insightful

This article is pretty interesting, but it is built on the assumption that vulnerabilities usually don't have exploits in the wild until the patch comes out. Sometimes that is true (as his examples show), sometimes it is not. The problem is showing the difference.

It is very difficult to establish what new exploits are being used in the wild. With the exception of viruses and worms (which have an analyzable payload), most exploits must be caught in the act to understand what they really are.

So if Company X has a vulnerability, they can:
a) hold off on a patch since there is no exploit (as the article suggests), or
b) patch right away, since there is an exploit in the wild

Option a saves Company X money....how hard will they look for an exploit?

--
Premature optimization is the root of all evil

Re:Exploits are often hard to detect... by DA-MAN · 2004-04-13 08:25 · Score: 1

This article is pretty interesting, but it is built on the assumption that vulnerabilities usually don't have exploits in the wild until the patch comes out. Sometimes that is true (as his examples show), sometimes it is not. The problem is showing the difference.

In his article he also equates the fact that the exploit came out for ISS's software immediately after the patch was released. Eeye had found it 10 days before the patch was released, why does he assume that the only ones that had found it and knew were Eeye and ISS?

It's just as likely that the software developers and the coders were both working on the same issue , one to exploit and one to patch. It could just as easily have been the exploit and then the patch. We don't know how the exploit was created, when it was started and how much time they worked on it. And as long as that is the case, bugs need to be fixed asap.

--
Can I get an eye poke?
Dog House Forum

Will they make us pay? by obsoletemind · 2004-04-13 07:47 · Score: 1, Interesting

If they release Patches further apart from each other, possbibly then on cds, will we have to pay for them as there will, i would presume, be a lot of data on these cds. Would you want that?

I HEAR THERE'S THIS NEW FANGLED MACHINE CALLED... by Trolling4Dollars · 2004-04-13 07:48 · Score: 0, Offtopic

..a computer! And man is it supposed to do wonders fer security. It's much more flexible than machines made before it because it isn't fixed in what it does. With the appropriate instructions this consarned machine might even make coffee for you one day folks! I hear tell that this machine can do millions of things a second. One of them millions of things is monitoring your network for break-ins and infections. Hehehehe... well I'll tell ya, what good is a machine that can do a million things a seconds or more when I've only got two hands and a gun! But, these here innovators at some new place that just set up a shingle in town are trying to get folks interested in something called Winders. They say it's more secure than Fort Knox on a Orange Alert day in June! I guess in some way, it kind of gives you millions of hands to control all the levers and pulleys in this here computer but you only have to use one or two hands. Them smart alecks might just have something there. But then again what do I know? I'm just a simple farmboy from Columbus Ohio. (That's A-hya to you furiners!) Bee-sides... what the heck am I supposed to do with my gun rack when these odd little boxes ain't big enough to stick one on 'em? Oh yeah, I also heard there's also some commie idiots who's got designs on the machine as well. Some guys named Linus Torvalds and Richard Stallman. I'm tellin' ya, I just don't like the sound a them two boy's names. What kinda names are Torvalds and Stallman anyways? I don't think they're good christian Americans. We gotta keep this country safe from them there terrorists and if'n security is gonna be a big deal, then we can't be havin' none o them un-christian gypsie makin' these machines! It just wouldn't be secure! Something's rotten in Denmark if'n ya ask me. So we have to be careful and make sure no dirty commie or devil worshipper gets their hands on one of these here computers. After all if the devil will find work for idle hands, imagine what satan would do with millions of idle hands in a computer!

[Pop tongue out of cheek now]

--
Un-news

SHHHHH!!!! by Anonymous Coward · 2004-04-13 07:50 · Score: 0

For God's sakes be quiet.

I LIKE Linux, so please stop giving them ideas. :)

Re:In case the site falls over.... by cavebear42 · 2004-04-13 07:50 · Score: 2, Insightful

Computer world isn't going to "fall over." If it does, we could post the article then.

WHY do we mod up people who pollute the comments by copying the article into the comments?

Not informative. damn, where are my mod points when i need them?

I completely agree with this article... by jamonterrell · 2004-04-13 07:50 · Score: 1

Because we all know that only researchers and vendors who report their findings to CERT immediately are capable of finding problems in code. And we also know from his article that the only way to create an exploit for a vulnerability is to wait until the patch comes out and reverse engineer it.

Okay, honestly though, I can agree with some of his arguments, they are fine, but to make backward assumptions like they did by not mentioning the fact that black-hats can actually find and exploit vulnerabilities for months before a single report makes it to CERT or to the vendor is just irresponsible journalism.

--
I can count to 1023 on my hands. Ask me about #132.

It never says that. by oneiros27 · 2004-04-13 07:51 · Score: 4, Insightful

You're just reading it in. It is however, stating that attacks seem to come rather quickly after patches are released.

Personally, I'd prefer if they didn't use valid scientific methods to prove if this is or isn't the case, if the result is network being saturated when the exploits finally hit, and manage to take out a significant number of hosts.

One of the key points that he didn't mention is that there was an attack about two years ago (sorry I can't be more specific, I was working on other projects at the time, as wasn't responsible for cleaning up after it where I worked), that one of the virus companies had a 'prefered customer' system, where they'd let certain customers know about virus outbreaks before the general public, and put out a press release that if you had been one of their clients, you'd have been protected from the virus outbreak. [I think it was one of the more hard hitting ones, too...like CodeRed, or at least near that time]

I would think that the issue that this article is talking about has absolutely nothing to do with speed -- it comes down to issues with the current procedures being exploitable, and needing to be fixed. He is simply giving a recommendation to fix the problem, which has a (not quite desired) side effect of longer times before systems are patched.

I would think that there's most likely some other solution out there that would have the desired end result (more difficult to reverse engineer the patches before the majority of users have patched their system), without creating some sort of intentional delay in the procedures. (and whoever comes up with it should probably patent it, to protect themselves and screw others, or should make sure to get it published, so it can be claimed as prior art before someone else patents it)

--
Build it, and they will come^Hplain.

Must be an MS slant by Anonymous Coward · 2004-04-13 07:52 · Score: 0

... slow it down! we have to reboot every time a patch comes out! ... hrmm, ok, so either a) it's a kernel patch or b) you're running a Microsoft OS.

Houston, I think we've located the common thread here.

Hrm by ReciprocityProject · 2004-04-13 07:55 · Score: 3, Interesting

For example, the patch for the SQL Slammer worm was released six months before the exploit was launched. This long delay enabled blame to be placed on lax systems administrators for not properly patching system

What are you talking about, "enabled?" It is their fault for not properly patching the system.

Ultimately, more systems will be developed using managed code (for example, Java and C#). This will narrow the problem to the bootstrap code those systems rely on without every application developer needing to be hypervigilant about buffer overflows.

That only makes sense if you think buffer overflows are the only security risk. Using Java doesn't magically make programs secure. In fact, a lot of damage can be done even when you don't have the ability to run arbitrary code on a remote machine.

Lastly, and most importantly, once the patch was released, the exploit was released the very next day. This wasn't a coincidence where the exploiters just missed having a zero-day exploit. If the patch had been released a week earlier, the worm also would have come out a week earlier.

So it doesn't matter in the slightest how often you release patches, exploiters will exploit them. Nothing in the article explains how delaying a patch release will make the system more secure.

[To make the system more secure] . . . software owners would subscribe to an automated patch service. . . . Subscribers would receive a predeployed, encrypted version of the patch.

That entire statement sums the entirety of the useful information in this article. Erase the whole thing and leave that statement. (I'm mean. Sorry.)

--

Upstairs Dog, Downstairs People.

Re:Hrm by DA-MAN · 2004-04-13 08:31 · Score: 1

[To make the system more secure] . . . software owners would subscribe to an automated patch service. . . . Subscribers would receive a predeployed, encrypted version of the patch.

That entire statement sums the entirety of the useful information in this article. Erase the whole thing and leave that statement. (I'm mean. Sorry.)

I see a logic flaw, i mean how hard would it be to run a program that scans the machine and makes a baseline install the patch and then rescan the machine for changes. Not hard at all, this would leave you with an unencrypted patch. Microsoft includes a tool to do this very thing in Win2k Server CD.

I don't see how this could help any, AT ALL. I see this as a way to make money for software companies (you will probably have to pay for this subscription service) and making it harder for Joe User at home to get their hands on exploits. Sure companies won't get hit as hard, but Joe will. Being Slashdot, let me phrase it in Slashdot terms... Imagine a beowulf of Joe user's computers DDoS'ing, spam relaying and overall being bad internet neighbors. Not too different from the situation now, except that at least now they have a choice to install those damn patches.

--
Can I get an eye poke?
Dog House Forum

Professional software development by Anonymous Coward · 2004-04-13 07:58 · Score: 0

every week there's a few stories about a new MS hole that's being exploited but that they refuse to (or cannot) fix.

Maybe that's because it takes time for the fixes to percolate through the system that actually includes a quality control system...

Re:Professional software development by Anonymous Coward · 2004-04-13 08:31 · Score: 0

If they kept the Programs more apart and didn't integrate explorer into the fucking kernel it would probably be a little easier for them.

Translation: by Gothmolly · 2004-04-13 07:58 · Score: 2, Funny

"Help, I can't keep up with the patches, because I told my boss that we could cut the budget by switching to Windows, and its turning out to be the opposite!"

--
I want to delete my account but Slashdot doesn't allow it.

Not about slowing down the cycle by merlin_jim · 2004-04-13 07:59 · Score: 5, Interesting

This article is not advocating slowing down the security patch cycle; the slashdot title is misleading... the author is advocating slowing down the security patch distribution method.

He makes the point that as soon as a patch is available, it is reverse engineered and exploited. He is advocating sending out encrypted versions of a patch, get everyone who is always-connected to the internet to automatically download the encrypted version, and once the downloads per second curve decreases by a certain amount (say 95% or so), then you send out the decryption key. Everyone installs the patch simultaneously; and zero-day exploits have as targets only those systems that do not subscribe to the patch service, and use traditional methods to procure patches.

This is based on the assumption that zero-day exploits reverse engineer patches. I have found this not to be the case; they usually just exploit the vendor description of the vulnerability; in many cases, this description is posted to a security mailing list a few days (or weeks depending on the vendor) before a patch is available; usually this is the method by which a vendor finds a vulnerability.

This process is right and proper as it gives the vendor a huge incentive to correct flaws quickly; many people who discover a vulnerability report it to the vendor, wait for it to be fixed, and then when a fix is not apparent, report it to the community to give the vendor a sense of urgency. Unfortunately, it is a necessary part of the security patch cycle; without it, we would have a priviledged few individuals who could write truly devastating worms and virii, for which the vendor may not even be working on a patch.

SQL Slammer was bad. But imagine it if Microsoft had no intention of correcting the vulnerability at the time it hit. How many more people would it have hit, considering that a significant portion of Microsoft's customers had already patched at that point? How long would it take Microsoft to issue a patch? How would they distribute it with so much of the internet simply unavailable? How long until our infrastructure approached something like normalcy?

That's what could happen in a world where public forums don't hold vendors accountable for fixing vulnerabilities. And that's exactly the kind of world necessary for it to make sense to slow down your patch distribution.

--
I am disrespectful to dirt! Can you see that I am serious?!

Re:Not about slowing down the cycle by greppling · 2004-04-13 08:42 · Score: 1

Yes, the author does talk a lot about slowing down the release cycle. You are right that the only concrete suggestion he makes is just about changing the patch distribution method.
But that suggestion (distributing the patches encrypted to all subscribers, and then publishing the decryption key) is so ridiculous that of course it didn't make it into either the main part of his article, nor into the slashdot summary: He wants to speed-up the patch installment. But this only saves the 5 minutes to download a patch, which are of course the smallest part of the time it takes to install a patch for a competent sysadmin that does some minimal testing before rolling it out. (And for a non-competent sysadmin that lazily waits 2 months until he gets horrified by reports about exploits, too.)
Pretty much the only change would be that the encrypted patch carries the message for the sysadmin: "Hey, wake up, there will be a patch to install tomorrow." The same effect could be achieved by a short notice on the relevant security mailing list. And I think there is a good reason why vendors excactly do NOT do that.
Re:Not about slowing down the cycle by Frizzle+Fry · 2004-04-13 09:41 · Score: 1

He is advocating sending out encrypted versions of a patch, get everyone who is always-connected to the internet to automatically download the encrypted version, and once the downloads per second curve decreases by a certain amount (say 95% or so), then you send out the decryption key.

This doesn't seem to avoid the problem. You'll have some people who've downloaded and used the encryption key before others, just like you would now with the patch itself. You could have everyone automatically download the key at the same time, but that doesn't seem better than just having them all download the patch at the same time in the first place (except maybe for very large patches where the time to download it is a factor).

--
I'd rather be lucky than good.
Re:Not about slowing down the cycle by DarkHelmet · 2004-04-13 10:37 · Score: 1

...and once the downloads per second curve decreases by a certain amount (say 95% or so), then you send out the decryption key. Everyone installs the patch simultaneously; and zero-day exploits have as targets only those systems that do not subscribe to the patch service, and use traditional methods to procure patches.
Out of curiosity, how would the company be able to "send" the decryption key, whereas all the machines run the patch at the same time. It's not like all the computers in the world run on a static IP. For that matter, what if the user is sitting behind a firewall, etc.
I suppose you could have your patch program preset to check their server at a certain time intervals, where the server sends back a response to check back in xxxx seconds.
Then again, imagine if Microsoft did this, and programmed all Windows machines connected to the net to check windows update at 12:57am for a decryption key. Can we say, DDOS?
I suppose it would be possible to even out the download interval of the decryption key over say... 24 hours. But then again, the witty worm struck 24 hours after the patch was released. I'm sure that with an effort, a virus like witty could be released during the patch timeframe and still affect a great deal of users.
Finally, patches for windows come out as exe downloads looong before Windows Update updates come out. This would have to change, and in the process it'll piss off a lot of network admins.
I could be wrong on some of my points. Feel free to clarify them, if I am.

--
/^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}$/i
Re:Not about slowing down the cycle by 10101001+10101001 · 2004-04-13 11:22 · Score: 1

This article is not advocating slowing down the security patch cycle; the slashdot title is misleading... the author is advocating slowing down the security patch distribution method.

Part of the patch cycle is the distribution and patching.

He is advocating sending out encrypted versions of a patch, get everyone who is always-connected to the internet to automatically download the encrypted version, and once the downloads per second curve decreases by a certain amount (say 95% or so), then you send out the decryption key. Everyone installs the patch simultaneously; and zero-day exploits have as targets only those systems that do not subscribe to the patch service, and use traditional methods to procure patches.

First, none of this seems to indicate it'd actually help for the *lazy* administrators. Why? Because most lazy admins won't subscribe any more than they'll use auto-update tools. So, the major thing which seems to be the aim of accomplishment is the responsible admins have a shorter interval between patching and when other people can reverse-engineer and make an exploit.

Of course, with something like MS's distributed update service, the patch is d/led once to a server and the patching is done at LAN speeds (the patch has to be sent over the LAN, either way), so the responsible admins should actually patch *sooner*, since at minimal they don't have to get and send the decryption key (nor wait for it).

This is based on the assumption that zero-day exploits reverse engineer patches.

Just so you know, zero-day exploits involve exploiting something *before* the patch is released, so the only possible zero-day exploits would be from reverse engineering a patch is if one of the alpha testers is doing it.

--
Eurohacker European paranoia, gun rights, and h

The goal of this author by Ice+Station+Zebra · 2004-04-13 07:59 · Score: 2, Troll

Is to create questions in the CIO's head about open source and software updates in an attempt to make open source look bad. Remember it was just a little while ago that Bill Gates told all the crackers the only security holes they found were from reading security patches.

My company thinks like that... by Beek+Dog · 2004-04-13 07:59 · Score: 3, Funny

They sent out a memo on cardstock (assuming people would actually read it if it was cardstock) telling us to cut down on the number of unnecessary copies and duplicate forms. We have 4500 employees. They told us to use email instead. Then they sent out a memo (regular paper. I think they could hear us laughing already) stating that they were blocking all attachments. I hung that one on my wall. And made copies.

Uninformed or just stupid ? by morcego · 2004-04-13 08:00 · Score: 5, Interesting

The degree of ignorance demonstrated on this article almost left me speachless. Not only the logic, but the data he uses is so flawed, that I should be laughting hard right now, except for the possible consequences of the article.

Just because a Worm was released right after the patch was released, it mean that they used the patch to create the exploit ? That is simply being obtuse.

Real cracker (or whatever you like to call them) are not there to make their name. They are out there to make a profit. Simple as that. Those are the guys with real motivation (and I mean money) to explore all possibilities. I do agree that the kids that make the worms to became famous among their 13371 frieds won't spend days working on disassemble code, but you can be very sure someone willing to compromise an specific target (a bank, or a given company) will do that. Add a little social engeneering to the mix, and things get real ugly.

Usually, worms are released after the patch. True. That is usually when the so called "zero-day" exploit becames useless, or nearly so. Also, releasing a worm is a good way to divert the attention from the other bug the cracker will be exploiting. Believe me, I have seen companies with 400+ employess come nearly to a halt due to patch deployment after a new worm shows up.

So, slowing down patch releases will slow down new worms ? At first glance, yes. It will also multiply the number of active worms on the wild, and allow the bad-bad-bad guys to keep making money, and cause real trouble, the kind of trouble take can take a company out of the market.

--
morcego

asd by manitee · 2004-04-13 08:05 · Score: 0, Redundant

Better patch notification and distribution is needed from almost every major vendor.

--
Four-digit slashdot ID. Recognize.

yet again. by happyfrogcow · 2004-04-13 08:06 · Score: 4, Insightful

The article seems to be making yet another claim that security through obscurity is better. They say that the patch release contains enough information for an exploitation to be made immediately if there isn't one already:

The patch had the specific information embedded in it that the exploiters needed, and the exploiters already had the expertise and tools required to rapidly make use of the information.

Slowing it down won't do anything, and they jump to that conclusion at the last line. Slowing it down, will have the same effect of speeding it up. They used speeding it up as an example:

If the patch had been released a week earlier, the worm also would have come out a week earlier.

The same could be said if it were released a week later.

Slowing the quickness of release shouldn't be a factor, only implementation of distribution. If they can find and fix a problem *right now*, why wait 2 weeks to distribute it? I just don't get why they mention time as an issue, except as flamebait.

End users are in a dilemma, however, because the current method of deploying patches doesn't allow them enough time before an exploit based on reverse-engineering of the patch can be deployed.

The only dilema is that of the producers of software. How fast can we notify end users that a fix is available and if they don't install it, they will be vulnerable to some attack.

If someone understands why the article claims slowing down will benefit, please explain to me. This is pissing me off. It makes no sense. The only thing that makes sense is their statement about a "patch subscription system". But that is crying out "Pay for this service". So they want to make people pay to have quick security patches, the rest get slow patching? I don't get it. I give up trying.

It's like saying "hey, what i want to do makes no sense at all! therefore it HAS to be good, new, and innovative. So give us money!"

Re:yet again. by Anonymous Coward · 2004-04-13 09:39 · Score: 0

The article seems to be making yet another claim that security through obscurity is better.

Your comment seems to be making yet another karma-whoring statement about security. The article did not imply that in any way. Besides, you didn't even finish your statement. Better than WHAT?
Re:yet again. by happyfrogcow · 2004-04-13 09:54 · Score: 1

Fine, for your obtuse brain:

The author is claiming that security through obscurity is better than security through allowing problems in the system to be freely discussed and criticized. The author claimed that exploits are directly derived from patches and alerts, and that not publicising until the patches were installed would reduce the number of exploits.

patches and alerts have never been necesary in creating an exploit.

Slowing patches doesn't work by dre23 · 2004-04-13 08:07 · Score: 3, Interesting

This guy doesn't even know the meaning of zero-day. Zero-day means that the programming bug has existed since the software was written. That means that if you discover a bug in Linux 2.6.x kernel, that bug has been around since the Minix days! It has nothing to do with being "elite" -- that's all the kiddie mumbo-jumbo.

Security "experts" (have you ever met any? oh really?) are confusing topics here. This is the same argument I've seen time and time again in the security world. Here are a few examples:
1) chroot environments
2) stack protectors

In the case of chroot environments, people were wanting to protect 99.9% of remote attacks because "kiddies" used remote buffer overflows as the primary method of breaking into computers. What happened? Somebody figured out ways of breaking out of chroot environments. It wasn't difficult. Now, kiddies and damn near everyone can read about how to break out of chroot environments. They don't protect anything when the technique/knowledge of how to break them is so widely available.

In the case of stack protectors, people again wanted to protect against 99.9% of the attacks. In this example, it's more clear because new attacks became available because of the protection methods. Buffer overflows were 99.9% of the attacks back in the day. When stack protectors started popping on the scene, tons of papers and research went into heap overflows, format string holes, shared library injection, et al. Now, buffer overflows represent maybe 60-80% of the exploits out there. Since the other methods are now well-known, stack protectors are not anywhere near full-proof, and becoming less so by the day.

Exploits are found in the wild. Anyone with ASM or C knowledge can find them, however some attacks require different ways of thinking and different coded implementations. There are many attacks against HTTP, for example, that require no knowledge of ASM or C. Anyone with the desire to find an exploit in almost any computer PROGRAM or line of code (and how many lines of code are there?).... will find one. Give a person a 6-pack of jolt and a box of Cap'N Crunch cereal, and that person will break code for fun or for profit.

Slowing down patches just makes the real hacker's results worth more. And software bugs (which what security holes are) can cause mass hysteria and even human death. Why delay a patch to a fix that could cause events such as historical software-related disasters? I see delaying patches as Armageddon. Who's with me on this?

--
IPv4 allocations for hobbyists? join the ipalloc-l mailing-list! www.operations.net/mailman/listinfo/ipalloc-l

Re:Slowing patches doesn't work by Minna+Kirai · 2004-04-13 10:14 · Score: 2, Insightful

This guy doesn't even know the meaning of zero-day. Zero-day means that the programming bug has existed since the software was written.

No. Where did you come up with that odd definition?

That means that if you discover a bug in Linux 2.6.x kernel, that bug has been around since the Minix days!

By that interpretation, a zero-day bug would be so rare we wouldn't even need a word to describe them! (BTW: Linux has never contained any Minix source code)

Zero-day really means that the person running the exploit is the one who found the hole. Or a little more loosely, it means that some attackers are aware of the hole, but the software author or public at large is not (not truely zero-day, but appears that way to outsiders, as they don't know when the flaw was spotted).

By extension, an exploit that is used after the flaw becomes publically known might be a 2-day or 10-day rootkit, or however much time has elapsed since the disclosure.

Compared to script-kiddies who download rootkits from others, zero-day hackers are a threat that a sysadmin can't avoid by obsessively watching for security announcements. Zero-day approximately means "before there are any security announcements".

(Addington's article was incorrect about "zero-day" as well. He claimed it has something to do with not using trojans or viruses, which is actually irrelevant to the meaning)
Re:Slowing patches doesn't work by dre23 · 2004-04-13 10:49 · Score: 1

You gave 5 definitions, I gave one. My definition is the definition that has been used to describe the security bug process for as long as I've known the industry (12+ years). What security terminology hasn't been twisted and marketed?

Maybe my Linux/Minix analogy was bad, but I'm sticking by the definition for "zero-day". It means that the bug was a bug out of the door since it was written, only to be discovered now (days/weeks, but usually months or years later). If I were to extend the definition at all, there is some assumption that the bug finder is not the original writer.

A zero-day exploit (not necessarily and also usually not written by the same person or team who found the zero-day bug) would then mean that the exploit affects every version of code that has been released. It has nothing to do with the timing of the release (at least in my world, using my definition).

Putting an official time on a "found bug" is impossible. No one really knows, and to argue or claim you or someone else did is an invalid argument. It reminds me of fights between my sister and I when we were 4 and 8 years old... "I found it first. No I did. No I did. Infinity!!!".

--
IPv4 allocations for hobbyists? join the ipalloc-l mailing-list! www.operations.net/mailman/listinfo/ipalloc-l
Re:Slowing patches doesn't work by Nejaa · 2004-04-13 12:47 · Score: 0

In a more general sence, "zero-day" means "before the first day of availability."

IE: if someone was to buy a copy of a game before it was released in stores, he would have a "zero-day" copy of the game.

Applying this concept to this topic, a zero-day flaw would be one that is being exploited before a patch for said flaw has been released.

Putting an official time on a "found bug" is impossible.

It is not "found" bug, rather "fixed" bug that is used as reference; its easy to do that.

--
A wise man once said: "Never pick a fight with a man who buys his ink by the barrel."

There are two type of patch management by Anonymous Coward · 2004-04-13 08:08 · Score: 2, Interesting

I believe that there are two ways that patches should be managed. If an exploit is already available, the patch should be immediate -- what is there to wait for? If an exploit is not available, a patch should be released at the end of the month, say.

However, if you have just discovered a vulnerability in your software, odds are some black hat hasn't just coincidentally discovered the same thing, so releasing a patch immediately is not likely buy you much security. Anyway, releasing a single patch when a bug is found is not a problem. What gets to be a problem is when 10 bugs are discovered in a given month, and people need to patch 10 times. This creates 10 times as many opportunities for somebody to exposed to an exploit because they didn't have a chance to have their system patched. Also, there is no predictability, so a good admin has to constantly poll for patches! If there was a predictable schedule (say, the first Wednesday of every month at noon), a good admin could plan for it, even arrange vacations around such a time.

Additionally, the author has an excellent point. Many exploits are derived from the patches themselves, so by delaying patches until a predictable time, vendors are actually delaying exploits until users are more likely to have their systems patched!

aQazaQa

Buffer overflows. Why? by Pig+Hogger · 2004-04-13 08:09 · Score: 1, Troll

From the article:

By far, the most common type of exploit is the buffer overflow, and software vendors are spending millions of dollars to find and prevent these types of vulnerabilities. These vulnerabilities still exist -- they are getting fewer in number, however, and finding them is now much more difficult. Part of my consulting practice to software vendors and their major customers is finding and reporting these types of vulnerabilities. Where I used to be able to do the "find vulnerabilities blindfolded with one arm tied behind my back" routine, I now actually have to work to find them in major software products.

Why use a primitive language (C, C++) that is nothing but a glorified assembler that likes to pretend it is a high-level language to write apps? Granted, there is muchos macho appeal to work in C, but if the resulting code is buggy like a chickenwire collander, what good it is to be a jock coder? (I am **NOT** impressed by clever code - and this comes from someone who worked a long time with Forth).

There are far better choices than C* to code programs; there is no excuse to write programs that offer buffer overflows for all to rape.

Re:Buffer overflows. Why? by October_30th · 2004-04-13 08:35 · Score: 1

There are far better choices than C* to code programs
Ok. Like what?
Please don't say Java. I know it's an old tune, but every Java application I've run has been ridiculously slow.

--
The owls are not what they seem
Re:Buffer overflows. Why? by TheInternet · 2004-04-13 22:23 · Score: 1

Why use a primitive language (C, C++) that is nothing but a glorified assembler that likes to pretend it is a high-level language to write apps? Granted, there is muchos macho appeal to work in

To a certain point, I agree. But there is a performance hit when using a higher level language. It's less of an issue on web servers because you take the hit "all at once" when the page loads. Desktop GUI apps have to constantly handle user events and deal with things like live resizing.

When software companies come out with products that are slower and take more system resources than the previous version, customers aren't necessarily thrilled. So higher level languages don't work for everything, but they can make software more reliable in many cases. I think it comes down to a case-by-case basis.

And writing core OS components in higher level languages... well, I just don't think we're there yet.

- Scott

--
Scott Stevenson
Tree House Ideas
Re:Buffer overflows. Why? by Anonymous Coward · 2004-04-14 00:47 · Score: 0

Because "everybody" knows C or C++, and very few people know Lisp or ADA.
Re:Buffer overflows. Why? by Vintermann · 2004-04-15 22:40 · Score: 1

Well, If you want fast compiled code much safer than C*, how about Ada95? If you are of a functional inclination, try OCaml. If you are a big fan of object-oriented design and implementation, try Eiffel or Dylan - as I recall the gang of four rather liked them.
All these generate fast compiled code, on the order of C++. If you're willing to sacrifice speed of execution you can choose between a LOT more, and it's just a fact that in most places sacrificing speed of execution for correctness and less development time is The Right Thing To Do(tm).

--
xkcd is not in the sudoers file. This incident will be reported.

OT Columbus OH LOL by dmaxwell · 2004-04-13 08:09 · Score: 0, Offtopic

They don't call it a cowtown for nothing. Where else outside of Texas can you drive through major shopping districts and see cows and horses out pasturing?

By this logic... by Anonymous Coward · 2004-04-13 08:10 · Score: 0

They should just not release the patches at all, since the exploits will never be found without them. I'm brilliant! Somebody hire me!

Apple is doing a great job... by mitchell_pgh · 2004-04-13 08:10 · Score: 1

The Apple security updates are rather frequent, yet painless for even the most novice user.

1) Click one button
2) Enter Password

There is no third step.

Re:Apple is doing a great job... by Anonymous Coward · 2004-04-13 08:26 · Score: 0

Actually don't they make you pay for your patches?

The patch causes the exploit?? by David+Hume · 2004-04-13 08:11 · Score: 3, Insightful

I dont know about everyone else, but if a bug or security hole is found, I want a patch for it ASAP, and not in 2 months when the next 'service pack' or whatever comes out.

I dont think the issue has to do with patches coming out all the time, but having a better way to install said patches. Lets just say I am really looking forward to Novells Zenworks Patch Management solution.

What if the distribution of the patch is, as matter of emperical fact, what *causes* the development of the exploit? From the article:

Lastly, and most importantly, once the patch was released, the exploit was released the very next day. This wasn't a coincidence where the exploiters just missed having a zero-day exploit. If the patch had been released a week earlier, the worm also would have come out a week earlier.

The patch had the specific information embedded in it that the exploiters needed, and the exploiters already had the expertise and tools required to rapidly make use of the information.

Now I know that this looks like a call for security through obscurity (see also here), but it is an interesting point. It appears the argument is that but for the distribution of the patch, there woudn't have been an exploit. I don't know how often that is true, if ever. But it does appear worth investigation.

As to your last point, the article indicates that the issue is not finding a better way to install patches, but instead finding a better way to distribute them without, if possible, also disseminating information that can be exploited by black hats. Again, from the article:

The main idea is that vendors need to rethink the patch distribution process, slow it down rather than speed it up and deliver security patches in a way designed to defeat the reverse-engineering process.

Is this possible?

--
Only Women Bleed (Sex, Sharia remix)

Re:The patch causes the exploit?? by gregmac · 2004-04-13 10:06 · Score: 1

It appears the argument is that but for the distribution of the patch, there woudn't have been an exploit. I don't know how often that is true, if ever. But it does appear worth investigation.

Maybe for closed-source software, but in the case of open-source, the hackers could just as easily follow bugtraq or the project's mailing list, see the discussion of creating the patch, and develop an exploit from there, before the patch is deployed.

--
Speak before you think
Re:The patch causes the exploit?? by srwalter · 2004-04-13 10:14 · Score: 2, Insightful

Now I know that this looks like a call for security through obscurity (see also here), but it is an interesting point. It appears the argument is that but for the distribution of the patch, there woudn't have been an exploit. I don't know how often that is true, if ever. But it does appear worth investigation.

It may be that it does happen sometimes, but more likely than not it happens the other way around. We've all heard about the MSIE holes that were floating around for weeks before MS released a fix for them. Fact is, if there are vulnerabilities, closed source or not, people will find them. They don't need the vendors to show them to us. From a logical perspective, unless somebody came up with an exploit already, the vendor would probably not have released a patch in the first place. It makes them look bad, having to release security patches all the time. Look at Microsoft, for example.

If it sounds like a call for security through obscurity, tastes like a call for security through obscrurity, and quackes like a call for security through obscurity, then it is a call for security through obscurity.

--
Freedom is the freedom to say that 2 + 2 = 4

Job Security by devobelisk · 2004-04-13 08:11 · Score: 2, Interesting

I don't know about you guys, but without exploits I would be out of a job. There would be no need for administration or security. So.. bravo Microsoft, keep up the good work. /me golf claps

Grandma doesn't have to be dumb to get spoofed by Anonymous Coward · 2004-04-13 08:12 · Score: 0

I can't think of many email viruses out there that can exploit the ol' "Do not open unless I know what it is" bug!

While you are right, I know too many people who refuse to learn that unexpected e-mail with strange subjects generally didn't come from the friend whose e-mail address it claims to be from. That isn't solely a function of the intelligence of the user. As humans, our instinctive methods of authentication work best face to face. Because we recognize voices and handwriting, they can be extended to telephone and handwritten text to a smaller extent. Once we get to typed text, especially in terse e-mail, it starts to break down.

Simply put, I have received valid e-mail from friends with a subject line that said, "You have to read this" and a body that contained nothing but a URL. I've received messages that fit that same description that are trojan spam. Grandma, at least the average grandma, is not going to be trained to recognize spoofed headers. We can raise the bar for the difficulty of exploiting security holes, but I doubt we can eliminate them so long as we want to continue sending each other arbitrary stuff.

Re:Grandma doesn't have to be dumb to get spoofed by cexshun · 2004-04-13 08:16 · Score: 1

Yes, but is grandma also going to keep current on patches? You either have to teach them semi advanced computer skills, i.e. what patches they need to download, or you must teach them common sense. However with a 70yr old person, teaching either is near impossible!

Not all right, but not all wrong either by emurphy42 · 2004-04-13 08:14 · Score: 5, Insightful

Here's my analysis of some claims stated or implied in the article:

Some exploits are reverse-engineered insanely quickly from patches. (True, with an example cited.)

Slowing down patches will reduce the total severity of exploits. (Way too vague.)

Slowing down patches will delay the existence of exploits. (False; not all exploits are reverse-engineered from patches.)

Slowing down patches in a "Tuesdays only" fashion will make it easier for admins to check for patches on a predictable schedule, and install them soon after they're released. (True as far as it goes, but the reverse-engineers can also check for patches on a predictable schedule; this also totally ignores exploits that aren't reverse-engineered from a patch.)

Slowing down patches long enough to make sure they don't cause some other severe problem is a good idea. (True, but not mentioned in the article.)

Providing patches in an encrypted-but-usable form right away, and in a decrypted form later, will help admins keep ahead of reverse-engineers. (Obvious "this is anathema to OSS" aside, how would this actually work? Windows Update patches are already distributed in binary-only form, and they still get reverse-engineered.)

Managed-code languages like Java and C# will eliminate buffer overflows, which are a common source of exploits, but they're nowhere near universal. (Basically true, probably with numerous exceptions and caveats.)

Re:Not all right, but not all wrong either by emurphy42 · 2004-04-13 08:30 · Score: 1

After reading some other comments, I think I may have misunderstood the encrypted-patch concept. It seems to be an improvement on automating the "Tuesdays only" concept.

1) Encrypted-and-not-yet-usable patch is posted.
2) Machines subscribed to the patch service auto-download the patch and put it in a holding area. This takes a while.
3) After a while, the decryption key for the patch is posted.
4) Machines subscribed to the patch service auto-download the decryption key, decrypt the patch (making it usable), and install it. This is near-instantaneous, because the size of the decryption key is peanuts compared to the size of the patch itself.
5) Admins of non-subscribed machines can manually download the patch any time after step 1, and decrypt/install it any time after step 3. So can reverse-engineers, but now all the subscribed machines are one step ahead of them.

An intriguing idea, and not even anathema to OSS any more (the source becomes available within a reasonable time period). Automatic updates still deserve careful attention, though, especially given the past history of patches that broke something else.
Re:Not all right, but not all wrong either by Minna+Kirai · 2004-04-13 10:22 · Score: 1

not even anathema to OSS any more (the source becomes available within a reasonable time period)

More importantly, the source becomes available as soon as the binary does- they can both decrypt at the same time. (Because until you recieve the key to decrypt, you don't really have the contents, in an intellectual-property sense)

My interpretation of the "slower release of synchronized encrypted patches" idea: Assuming that it's true that many exploits are written based on analyzing published patches, this may improve the security of lazy sysadmins who don't work hard to keep up with patches.

However, it will harm the security of obsessive, paranoid admins who check for new vulnerabilities twice a day, and pull down servers if a hole is announced before a patch is released. Those guys were already quite secure from known flaws. But for protection from unknown (zero-day) flaws, they rely on vendors publishing security updates ASAP.

In short, the plan will reduce the security of those people who care about it the most, by making them equal to the lazy guys whose data evidently isn't valuable enough to protect.

In my view, that's the wrong tradeoff to make. Reducing the best to improve the average... it's plain old un-American!
Re:Not all right, but not all wrong either by grupo-xenon · 2004-04-24 11:48 · Score: 1

At last a thread of where people actually get the article. I also think you are the only person who realized "median time to patch" with the solution suggested would actually improve. The reason to improve the average is that some exploits (Slammer for example) cause problems even for those who already did the right thing or are not even using the affected system. Also any workable solution must address the mass of computer users, not just the gearheads who subscribe to patch notifications on their Blackberries.

If an active exploit was discovered, the system could immediately release the keys and those who downloaded the patch already would be instantly immumized.

So good I thought I'd repost by Anonymous Coward · 2004-04-13 08:15 · Score: 0

If you agree with any of this, feel free to repost it in the future.

* If "Linux" just refers to the kernel and not the operating system, how can "FreeBSD" refer to the operating system (userland tools, standard libraries, etc.) and not just the kernel? Face it, "GNU/Linux" looks and sounds ridiculous.

* If you expect companies to follow the copyright of the GPL, you should support the RIAA going after infringers of its copyright. If not, you're a hypocrite.

* There is absolutely nothing wrong with a company being upset that its product is being pirated freely over online networks. Try getting a real job sometime and see what it feels like when your work is everywhere, and you start worrying that your days are numbered. Does John Carmack want you to "sample" his new game via the "free advertising" happening on eMule?

* OSDN-owned Slashdot thinks its niche opinion represents the majority of the world. This is a result of people visiting every day and buying into the groupthink. Nobody outside of Slashdot knows or cares about "Linux," "RIAA", "M$," or anything else Slashdotters think is such a huge issue in today's society. Go to a mall or coffee shop sometime and see what people actually talk about.

* Speaking of OSDN--it's a Linux company...that owns a "tech news" site...that posts news stories negative toward competitors like Microsoft. If a Windows company or even Microsoft itself owned a "tech news" site and posted anti-Linux articles all the time, everyone would be up in arms. But with OSDN, it's a-okay.

* Slashbots think people don't like the music coming out these days, which is the cause of the piracy. Never mind that if people didn't like the music they wouldn't be pirating it, most Slashbots--again, this goes back to the niche opinion thing--don't realize that most people these days love the music coming out and want to hear all of it. Probing around, you discover that Slashdot is made up of nerds and fogies who listen to things like The Who and Blind Guardian and techno--not what mainstream society enjoys.

* Any company ending in "AA" is evil. Especially if it doesn't want you distributing its works without paying for it. Somehow, this mindset is supposed to make sense.

* The inevitable result of all this is a world in which nothing can be profitable because people simply pirate free copies. Is that really what Slashbots want? OSS and free-ness in general reminds me of the hippie era of the 60s--idealistic socialism that only exists because of the surrounding capitalism around it that provides the environment for it to exist. We all know what happened to that idea.

* Slashdot editors are abusive. We all remember The Post. It's amusing the editors never mention the issue. The worst editor is michael, who will mod you down, insult you for your post count, and post unprofessional color commentary along with the article. This is the same bizarre person who cybersquatted Censorware for years--even as Slashdot posted articles negative toward cybersquatting! Michael played it off like he was some sort of stalking victim, which made it all the more bizarre.

* The moderation system is broken. If you mod someone as "Overrated," you can't be metamodded. People abuse this all the time to gang up and knock you down into oblivion.

* Somehow, user-ran executables are always a "New Microsoft Hole" (actual article headline). Meanwhile, LinuxSecurity [linuxsecurity.com] posts weekly security advisories for all the Linux distributions. You never, ever, EVER see any of these mentioned on Slashdot--bizarre things like arbitrary code execution via MPlayer.

* Microsoft is supposed to be some sort of non-innovative rip-off artist. Meanwhile, the same people posting those comments do it through KDE with taskbars, sidepanels, start menus, similar print dialogs, and an integrated web/filesystem browser. Effectively ripping people off then criticizing those who came up with the ideas in the first place.

* Linux is "ready for the desktop

Re:I want it fixed ASAP (the other half) by lexluther · 2004-04-13 08:18 · Score: 1

At some level we continue to forget that a majority of the problems dont revolve around wether a patch was released before or after but rather that the people are not patching the systems when a patch does exists. We all suffer because msoft users dont patch, or patch too late, and then the internet is flooded with useless emails. I believe the author has a point in making references to secure patch services, which will automatically patch machines for users who dont/cant do it themselves (albeit he is certainly not inventing the concept). Obviously, we would all be better if we wrote perfect code, but we know that this is not a reality, economic nor physical - Microsoft makes it so easy to use their operating system at some level, but then so difficult to apply patches, and remove viruses that automatic patching of windows should be the default and power users can just opt out and do it themselves, and the masses can live happily in their ignorance.

An angle I haven't seen before by theLOUDroom · 2004-04-13 08:18 · Score: 4, Interesting

While reading the responses to this article I came across an idea that hadn't struck me before:

What if the reason some of these exploits aren't happening until the patch has been released is because the blackhats are being careful not to break into systems that belong to clueful users (tm)?

The reasoning would be: -I want to break into a computer
-I don't want to get busted
-I want to make sure whoever I break into isn't going to bust me
-I'll pick a computer that obviously isn't having much attention payed to it -If a system isn't getting patched, it probably isn't being checked for intrusions either.

Now I'm not saying that it accounts for the majority of cases, but it is interesting to consider.

--
Life is too short to proofread.

hasn't this already been tried... by Chuck+Bucket · 2004-04-13 08:19 · Score: 2, Funny

...slowing down, not speeding up, patch releases.

Isn't this what Microsoft has been doing for years? (rim shot)

sorry, mark it as Obvious.

Cb

--
free ipod and free gmail!

His idea, explained so even slash posters can unde by mjm · 2004-04-13 08:19 · Score: 1

Here's the deal: he wants patches released quickly to... wait for it... paid subscribers. Non-subscribers will have to wait for a later public release, with the same problem getting the patch installed before the exploit hits as now.

Say, you don't suppose he's got a patent application under way for this business model, do you?

The stunningly obvious hole in his his logic is the assumption that the subscriber-only release will never get into the hands of the exploiters. In other news, pigs have been reported sighted by flight crews of commercial aircraft...

Remote buffer overflows or ???? by dre23 · 2004-04-13 08:21 · Score: 2, Interesting

Remote buffer overflows are not as big as many people say they are.

Computer systems are more likely to get compromised in the following two ways:

1) Poor choice of passwords. This is a vendor implementation problem. Computers and programs should not allow people to choose bad passwords. There should NOT be a setting to make this optional. If passwords aren't secure, why require them in the first place?
2) Exploiting a trust relationship of some kind. This is generally a protocol design problem, that quickly becomes a vendor implementation problem once found. If Microsoft stopped using old protocol/security technology to share files, print things, and authenticate users -- and adopted a SANE model where ports weren't open and available for the whole world to take over -- then we wouldn't have the remote buffer overflows, worms, or any of the big problems we have today in the security world. Patch management would mean "new features, less bugs" and not "save my computer from the worm of the week".

--
IPv4 allocations for hobbyists? join the ipalloc-l mailing-list! www.operations.net/mailman/listinfo/ipalloc-l

Stop Releasing Patches by caffeinebill · 2004-04-13 08:23 · Score: 3, Interesting

Clearly, if it is better to slow down the release of patches, it would be best to NEVER release a patch. That way, there is nothing to "reverse-engineer" and there is no way the "exploiters" will have nothing to work with. Better yet, don't even release the software in the first place, and no exploit will ever be found, even for the less lazy, more sophisticated exploiters who find bugs in the original code!!!

Partially Correct About C/C++ by EXTomar · 2004-04-13 08:25 · Score: 2, Insightful

I'm always bummed when people poo-poo C/C++ because they fail to see the real problem. It is true that C/C++ is probably too "low level" to do effective and safe application writing but that isn't the problem since one can clearly write bulletproof apps in C/C++.

The problem is that, like most bugs, the complexity of the language makes it hard to predict problems. Even in memory managed systems like Java and C# you can have crippling errors. You don't "fix" the problem by moving to these types of memory managed systems. You just contain and shift the problem from one place to another. A sloppy C# app will cause all sorts of havoc when an exploit is found in the way it performs.

The fix isn't avoiding C/C++. The real is rigorous code reviews to keep implementations clean and orderly so problems can be predicted. FOSS helps here but like any other venture it requires diligence to make it work effectively. No runtime environment is bulletproof and therefore will never be a substitute for plain old fashion inspecting of the code.

Re:Partially Correct About C/C++ by psykocrime · 2004-04-15 09:07 · Score: 1

Very well said. Here's a "virtual" +1 (Insightful) from me.

--
// TODO: Insert Cool Sig

Is this FUD? by krgallagher · 2004-04-13 08:29 · Score: 1

OK maybe it is a valid point that not only M$ is vulnerable. Still he uses an example that is intentionally designed to cause fear because not only is it a non-M$ app, but it is a firewall to boot. Next he proposes a solution that looks too much like Longhorn to be a coincidence.

"In one possible scenario, software owners would subscribe to an automated patch service. "...

"Subscribers would receive a predeployed, encrypted version of the patch. At a predetermined point, a decryption key would be passed to a patch installer on all subscribed systems." ...

"By the time the code exploiter even begins to reverse-engineer the patch, most affected systems would be immune. "

Am I the only person who imagines the "Code Exploiter" exploiting the patching system? I would never allow any process from outside my network to put software onto a computer on my network.

Interestingly I use a system similar to this but it is a pull not a push. SuSE has a system called YOU - Yast Online Update. I have it configured to automaticall poll for patches and install them during off peak hours. I believe Red Hat has something similar. The difference is I (or my computer) initiate the process. It leaves me in controll, not some mysterious "patch service."

--

Insert Generic Sig Here:

Not slow down, but wait and deploy more rapidly by EMIce · 2004-04-13 08:31 · Score: 2, Insightful

The slashdot blip about the article is misleading as usual. The author's main point is that it takes time for all systems to be patched, such that someone will reverse engineer the patch and release a rapidly spreading worm/virus before a majority of systems are patched. Simply slowing down the release of patches won't really help unless all vendors pick a regular patch release interval that people actually follow. This is what Microsoft appears to be trying, but the system is too dependent on people staying on schedule. The author says a fundamental change is needed, perhaps allowing encrypted patch downloads for some time, and having the patch installer wait for a key to install those patches simultaneously at a later date. This is clever and leads me to expand on the idea.

Why not have a standard piece of software that scans your system for different programs you have installed, one that registers the programs as well as your machine's ip address with a server? There could be a centralized server system or each vendor could have their own server to allay privacy concerns. Encrypted patches then could be auto-downloaded upon release and then held until some point in the future. Then simple UDP packets containing decryption keys could be sent to all registered systems - at least once enough of them have downloaded the patch - allowing near simultaneous installation.

An added bonus would be that if a worm/virus is reported in the wild, patching can commence immediately. This would really put a damper on the ridiculous rate of infection we usually see, currently so rapid in fact that anyone not patched is usually hit within a day. I'm glad most of these worms don't carry destructive payloads, the recent destructive witty worm killed my weekend. Try recovering data after random parts of the drive have been overwritten.

Re:Not slow down, but wait and deploy more rapidly by citking · 2004-04-13 09:12 · Score: 1

I think that your idea is great...in theory.

But, I don't want anyone but me putting stuff on my computer, whether it be a patch, virus defs, upgrade, etc. Yeah, self-updating technology is good for systems that aren't open for bona-fide consumer modification (like Dish receivers, cell phones, and TiVO) but a PC should only run what I want it to run. Honestly, how long would it take for some shady company to sell you CoolApp 1.0 for $5 but then relaease a "patch" that automatically bills you $19.95/mo for features that are now deemed necessary? While this is an extreme example I think that self-updating technology is only good in smaller, controlled environments such as a corporate LAN or university system...not the entire Internet.

Not only that, but firewalls, difefrent user configurations, security concerns, etc. could all impact an automated update process in very bad ways.

--
"This food is problematic."

Gray-Hats Patches by SphericalCrusher · 2004-04-13 08:32 · Score: 1

In a way, that could be a good thing and a bad thing. If they take a slower pace to patch things, then maybe they will fix the majority of the problems and create less when the new patch is applied. Now, in some cases, it could be a bad thing, as the black hats of the world would love to just pick that apart piece by piece just to see how secure those patches really are.

If more hackers would face themselves in a gray-colored aura, we'd see a lot more secure software in the world.

--
"Instant gratification takes too long." - Carrie Fisher

What if it's a bad patch? by menscher · 2004-04-13 08:34 · Score: 2, Insightful

There are occasional cases of a "bad patch" -- one that crashes machines, etc. I've seen a few over the years.

Now consider what happens when *everyone* installs at the same time. No chance for the vendor to get feedback and pull the patch. Somehow this seems risky....

Re:This will tick off C++ programmers but... by Anonymous Coward · 2004-04-13 08:40 · Score: 1, Interesting

Buffer overruns in Pascal are very unlikely. That is its strength.

People mod down what they do not understand.

Here's Why by blunte · 2004-04-13 08:41 · Score: 3, Insightful

I wonder why such a vapid article was posted?

It was probably posted so we'll be aware what PHBs are being fed.

It is NO wonder why it was written... from the bottom of the article:

Bill Addington is a software entrepreneur and inventor, operating several application service provider companies. His spinoff technologies have been sold to companies including America Online Inc. and Microsoft Corp. He conducts his security business in conjunction with Dyonyx in Houston.

He does have a point about reverse-engineering, but the solution to that isn't "don't release a patch". His article reads like a Microsoft HOWTO Cover Our Ass document.

One thing that would be interesting (but very difficult) to measure would be the relationship between exploits and fancy features. Fewer features/capabilities must mean fewer potential exploits. And if, as some estimates stated, Word 2000 users on average exercised 10-15% of the features it provided, one must wonder if the other 85-90% of the features were worth the associated exploit and bug potential.

Imagine Internet Explorer minus ActiveX, minus silently-installing "agents", and minus some of the magical integration with the OS. It might look something like Firefox (fast, clean, and comparatively exploit-free).

--
.sigs are for post^Hers.

Re:Here's Why by Anonymous Coward · 2004-04-13 09:49 · Score: 0

One thing that would be interesting (but very difficult) to measure would be the relationship between exploits and fancy features. Fewer features/capabilities must mean fewer potential exploits. And if, as some estimates stated, Word 2000 users on average exercised 10-15% of the features it provided, one must wonder if the other 85-90% of the features were worth the associated exploit and bug potential.

Oh, come on. I'm not aware of a single virus ever for the most bloated bit of software ever written. That could of course be because the language emacs uses, Lisp, is immune to buffer overflows...

Re:This will tick off C++ programmers but... by chgros · 2004-04-13 08:41 · Score: 2, Informative

If they wrote their software in Pascal, this wouldn't be a problem.
If they used STL string / vector, this would also probably not be a problem.
Not to mention, a buffer overflow in Pascal would make the program quit with a runtime error: great security!

International Software Upgrade Day? by Anonymous Coward · 2004-04-13 08:44 · Score: 0

What about doing a International Software Upgrade day?

Suggested encryption doesn't solve anything by dumky · 2004-04-13 08:44 · Score: 1, Insightful

The article recommends that the patches be encrypted when being distributed, this doesn't make it any harder to reverse engineer them.
Just install the patch on a box and do a before/after diff...

Re:Suggested encryption doesn't solve anything by emurphy42 · 2004-04-13 11:45 · Score: 1

I think you're tripping over the same thing that I tripped over at first.

Until you receive the decryption key, the encrypted patch is useless. You can't read it or apply it in any useful fashion - and if you can't apply it, then obviously you can't do a before/after diff.

You can, however, store it on your HD and wait for the decryption key to be posted - and this is exactly what the author is suggesting you do.

1) Encrypted patch is posted (it may be 500K)
2) Lots of machines download and store the patch (this takes a while, so you wait a while before moving on to the next step)
3) Decryption key is posted (it's only about 1K)
4) Lots of machines download the key (this is very fast because the key is small), unlock and apply the patch

Bad Writing by wonkavader · 2004-04-13 08:48 · Score: 3, Insightful

The substance of this article seems to be:
Catchy way of describing my idea (albeit misdirective)
Why we need my idea
My idea.

As you can tell from how Slashdotters are reacting, they never finished the article, or didn't read the whole of the last paragraph, where the idea of encrypting patches and distributing a key days or weeks later is actually stated.

It's a good idea. It solves badwidth issues for people with huge patches (Microsoft, in particular).

But he has so much in the first and second section and so little in the last section that his idea gets buried. I think he needs to make his ideas less mysterious. Give us some terms of the actually idea ("Slow down patches WITH CRYPTOGRAPHY") or something so that we actually READ the last paragraph.

Furthermore, there would need to be a darn easy way to do this for it to work. Microsoft's update feature could do it, as (we can pretend) every windows box has it.

If SSH has a vulnerability, you can release a patch this way, unless every OS it runs on has a automatic system -- one which gets patches and keys and installs patches when a key arrives. Red Carpet could be modified to do that, but what do the Plan Nine users use, the MacOS users, the FreeBSD people?

However, over time, such a system could get wide acceptance for configuration/vendor specific patches and then become useful for applications, as well.

It would have to be a well-defined OPEN system, and MicroSoft (it seems) need not be included -- they'd do their own thing and make the system non-portable.

RTFA dumbass by Anonymous Coward · 2004-04-13 08:49 · Score: 0

He advocates releasing an encrypted patch and giving out the key after people have a chance to get it.

Took them long enough by InsaneGeek · 2004-04-13 08:50 · Score: 2, Insightful

You kind of missed the point there. If you have something out running in the wild found you release a useable patch that day. He's talking about exploits found from the vendor, not ones out in the wild. i.e. when Redhat finds an extremely obscure buffer overflow not joe hacker. Instead of releasing a statement about the problem an hour after it's found, and then putting a patch out a day later, with admins patching couple of days after (a weekend you know) he's advocating that since nobody else knows about it: putting out an encrypted patch to the users to download over the weekend, then on let say every tuesday simultaneously unencrypt & activate all the patches, and send out a exploit report. With this method a greater percentage of the population will not have an issue with vendor found exploits.

He's not saying that all exploits are found in house, he's not saying that shit doesn't start outside, but he's saying if it's not in the wild now, why fuck over everybody on the internet over a threat that doesn't exist yet. If there is a threat release the day you find it, if there isn't it'd be nice to be able to wait for the admins to get over their weekend hangover.

RTFA by Anonymous Coward · 2004-04-13 08:51 · Score: 0

He does NOT advocate slowing down the patch cycle.

*bump* by blunte · 2004-04-13 08:53 · Score: 1

That is a very interesting possibility. If I were a spammer ^H^H^H^H er RIAA agent ^H^H^H^H er cracker, I would like to find the systems belonging to the most lax (or non-existent) sysadmins. That way I could own their box for potentially much longer.

And if they don't patch, what is the likelihood they do intrusion detection?

--
.sigs are for post^Hers.

To sum up.... by lcde · 2004-04-13 08:53 · Score: 1

I beleive he said it best:

This entirely misses the point.

--
:%s/teh/the/g

methinks by Anonymous Coward · 2004-04-13 08:54 · Score: 0

Methinks the moderator does not understand what the word "offtopic" means. Hint: posting about the current story is by definition ON TOPIC. lame lame lame.

It's a problem with the entire approach. by khasim · 2004-04-13 08:56 · Score: 1

I'll pick on Microsoft because they're an easy target.

#1. Poor security model. They install EVERYTHING by default and turn it on. You're running vulnerable services that you don't even know about.

#2. Patches that break working systems. There was the problem with the patch for the Blaster worm that broke RPC on NT4.0 servers.

#3. Which leaves it up to the administrators to constantly check for new patches and test those patches in their non-production network and deploy those tested patches to production machines in a timely manner.

And, just as you've noted, that only covers the patches that a vendor actually releases AFTER admitting to the vulnerability.

The current system (the one the author of the article is crying about) places undue dependence upon the LEAST reliable segment; the PERSON doing the administration.

His "solution" also gives the most latitude to the segment that should be working the hardest to solve this problem; the VENDOR of the buggy software.

Under no circumstances do I believe that extending the window of vulnerability would be a "good" thing.

The entire focus SHOULD be on making the admin's job as effortless as possible.

A. An easy way to determine what is installed on your system AND THE PATCH LEVEL.

B. An easy way to see if there are any security patches for everything in "A".

C. An easy way to deploy the patches in "B" to a test environment (because we always test).

D. An easy way to deploy the patches in "B" to the vulnerable systems.

My favorite is Debian because I can already do most of that, easily.

Re:His idea, explained so even slash posters can u by jtwJGuevara · 2004-04-13 08:59 · Score: 1

And this gives corporations and larger businesses the ability to conveniently patch their software the right way (or right by his line of thought) with no threat of attacks (at least reversed engineered cracks).

But as always, where does that leave the home user who is paying bills and can't put up money to _subscribe_ to a service that is mandatory for safe computing. It puts that user right in front of a fire hose with his/her mouth wide open with a cracker armed with malicious code ready to turn on the hose on full blast.

If I may expand upon that. by khasim · 2004-04-13 09:05 · Score: 2, Insightful

You are completely correct.

May I also point out that such is the case with the existing "anti-virus" market?

We see "patches" every week for the latest round of viruses. And we will continue to, until Microsoft addresses the actual vulnerabilities in their software (and the security model upon which it is based).

A virus or a worm (and, to a less extent, trojans) are all FAILURES in the security of a system. How many failures of an almost identical nature does it take before people realize that the model is flawed?

reward the crackers by Anonymous Coward · 2004-04-13 09:06 · Score: 0

What about releasing a 'pre-release' and reward every found security hole with say $10.000. Wait a month or so and then release the fixed software?

Just goes to show MS is better than lunix by Anonymous Coward · 2004-04-13 09:19 · Score: 0

Mod me down if you must, I know that everyone on here is anti-MS and that everything MS does is evil and MS has zero security, but I'm going to go against the conventional "wisdom" of slashdot. When MS has a security problem, they fix it, plain and simple. The user updates with a click or two, hell, they can even do updates automatically. Then you're done, end of story. What do I do if lunix has a security problem? Let's see... maybe I download a patch. Okay, and then I find the source to my application, whatever version that might happen to be then. So I apply the patch, recompile, and hope nothing breaks or that my config is still valid. Soooooo much better than "wind0ze", right?

Hell, 100-to-1 says Dick Cheney uses windows and not lunix. And if its good enough for Cheney its good enough for me. Propz to Halliburton.

Shhhhh! Don't tell anyone by Nejaa · 2004-04-13 09:26 · Score: 0, Redundant

So, basically he's saying this: If [hypothetical software company] finds a flaw in their software, they should keep it a secret. That way maybe nobody will figure out how to exploit it. Does this seem flawed to anyone else?

--
A wise man once said: "Never pick a fight with a man who buys his ink by the barrel."

It's not the patches, it's the KB articles! by Anonymous Coward · 2004-04-13 09:27 · Score: 0

The biggest problem with telling the crackers how to exploit things isn't the patches. It's the knowledge base articles. Disassembling a patch to see what's changed is a lot of hard work, when all you have to do is read the knowledge base article on the MS web site to get an idea of what to start hammering on to find what breaks.

Back when I was doing admin work on IBM mainframes, the doc on security patches would only say: security. They never told you what the problem was, or how to exploit it. I don't know if they've changed that policy since I worked on them.

John Roth

Here's a thought by bitspotter · 2004-04-13 09:37 · Score: 1

Sounds like an application for broadcatching .

Creating a torrent for each patch would ensure the fastest possible distribution, while the rss feed would ensure the timely announcement of it.

"broadpatching" ?

I was thinking along similar lines for distributing virus signature updates. What with "warhol worms" now routinely spreading faster than traditionally-downloaded (and slashdotted signature files, antivirus vendors need a more efficient distribution channel, as well.

I pity the hacker... by NotQuiteReal · 2004-04-13 09:42 · Score: 1

... who has to wade thru a 300 MB "patch" to find the one buffer overflow it fixed!

Aren't all MSFT patches about that big?

--
This issue is a bit more complicated than you think.

Re:I pity the hacker... by BoomerSooner · 2004-04-13 10:18 · Score: 2, Informative

They don't wade through 300MB, they do a diff on the dll's/exe's and find the location of the overflow, it takes longer to code the exploit than to find the problem. I'm learning assembly and my hobby is reverse engineering the install codes in software (learning only, and I'm not good by any means, yet). If you look for starter kits they tell you that WinZip (I'm not sure about current versions but older ones were "easy") is a good program to start learning how to look for instruction patterns to find where the registration routine is. The only thing you had to do was just jump past the routine.

Assembly is difficult but rewarding to learn. Plus there are so many great tools available now that weren't when I first got into programming (NASM, the Art of Assembly book, etc).

Windows Security Update CD by Deviate_X · 2004-04-13 09:55 · Score: 1

You can get a Free CD from microsoft containing security updates for Windows XP, Windows Me, Windows 2000, Windows 98, and Windows 98 Second Edition (SE). It also includes 1 year free anti-virus software and a firewall.

Windows Security Update CD - i ordered 1 delivery was also free.

Re:Windows Security Update CD by myov · 2004-04-13 10:45 · Score: 2, Informative

I've been waiting over a month for mine. I could have transferred the contents over dialup by this point!
(probably held up in customs, but still...)

One other thing I discovered is that MS automatically made a passport for me when I filled out the order form. It didn't say anything about that until I tried to check the order status and was redirected.

In response to the parent about changing WinXP themes... get a patched uxtheme.dll file. WinXP file protection will complain but you can ignore it. Then, you can use any of the third party themes. I use watercolor - a nice simple, clean theme. The florescent-green-on-blue-designed-by-a-4-year-old theme got to me. (one thing I love about OSX... the gui is functional without screaming in your face)

--
I use Macs to up my productivity, so up yours Microsoft!

Microsoft patches are not always perfect. by phobos182 · 2004-04-13 09:58 · Score: 0

Being a Sr. Network Administrator myself, I have to deal with the headaches of patch management on a large scale. What the author of this article fails to realise is that some patches actually break applications while they are fixing the security holes (Service Pack 4 anyone?). Microsoft recomends that you test patches before you deploy them. Software Update Services supports this as you approve patches before deployment. Having a "Payload" release to everyone at the same time without testing is just asking for serious problems. This method is flawed, and needs to be addressed. If there was a problem, the patch would become a worm unto itself. A worldwide release that breaks functionality from a trusted source.

OpenSSH tried this once by kasperd · 2004-04-13 10:05 · Score: 2, Interesting

One time (a few years ago, I don't remember exactly when) a flaw was discovered in OpenSSH. It was anounced that a bug had been found, and that a patch would be released one week later, such that every distributor could release them at the same time and administrators would be prepared to install them. That aproach was very similar to what this article describes. (Yes I actually read it)

It was a complete failure. It lead to some of the worst criticism the project had ever experienced. And they ended up releasing the patch earlier than announced, not because of the criticism, but because exploit code was being written despite of the patch not being made generally available.

--

Do you care about the security of your wireless mouse?

Re:OpenSSH tried this once by Tuck · 2004-04-13 11:43 · Score: 2, Informative

It was June 2002, and here are the details including a description of the release process.
At the time of the original announcement it was specified that there was a way to mitigate the problem (Privilege Separation) and at least some of the criticism was because PrivSep didn't work on all platforms.
The patch was released early because the discoverer released the announcement early. I don't know if there were exploits available at that time.
Disclosure: I'm one of the OpenSSH developers, but I wasn't at the time, so I only know what was made public.

--
$ find /pub -beer "James Squire Amber Ale" -drink

because it's fun to ... by zogger · 2004-04-13 10:38 · Score: 1

... razz the other guy. When I was a teen, it was your car. ford/chevy/dodge they all had wicked fast ones right off the showroom floor, all of them sucked gas so bad you wouldn't believe it, all had pluses and minuses to their design. Got in dang fist fights over it....Same old tune..

Great great gran pops day they proly did it with their horses. "My appaloosa can blow the sweat off'n yore nag, ya **&*&^^%^%!!1! quarterhorse fanboi!"

Same ole crap

I'm only impressed (really) with that one nerd we had here in an article, he built his own box from scratch, like he hand carved his CPU and whatnot. anyone remember that? That's some fair skills I say, at least he can brag it's really HIS box.

that is a variant on the two..... by zogger · 2004-04-13 10:50 · Score: 2, Insightful

... explosive devices weapon. The first one goes off (take yer pick, truck bomb, land mine, whatever). Everyone runs over to assess damage and to help clear rubble and tend to the victims and whatnot, then WHAMO, the second bigger one goes off, the one that really inflicts the damage.

Basic assymetrical warfare 101

and using the patch for the clues needed for the next round improved virus would be akin to stealing the materials you need for your explosive device from your target, in other words, frosting on the cake

that would be asym wf 102

ways to beat it? Easiest way is to not be a target.

I'll let anyone figger the analogy out how that applies to cyber security

Besides that, unless the web is RADICALLY changed and every device has an unspoofable publiclly see able IP that is external and unique, and that IP has an identifiable human connected to it, and all web traffic is logged..well, it'll just always be an arms race and an intel race. We got to ask ourselves, do we want a web like that, or put up with it like it is now?

Me, I'll take the security concerns over "safe"
big bro surfing.

Mod Parent Down by 10101001+10101001 · 2004-04-13 10:51 · Score: 1

From the article:

What about hackers taking advantage of the vulnerability in the meantime? What about those "zero-day" exploits? To answer this, we need to know how the researcher/patcher/exploiter cycle really works and the motivations of each party in the cycle. This cycle is where researchers discover vulnerabilities, software companies patch the vulnerabilities and hackers exploit the vulnerabilities.

A cycle is, by definition, a one-directional serial connection that returns to some previous stage. While it doesn't explicitly state that this cycle is the only cycle that exists, his whole solution assumes that it's the only cycle. Otherwise, logically, the exploits would already be in the wild and the best solution would be (*tada*) getting patches out as fast as possible.

In fact, zero-day exploits are based upon the idea of releasing something prior to there being a patch/official release. The day of the patch/official release would be day 1. So, this journalist obviously has a few issues, since he never tries to deal with them.

--
Eurohacker European paranoia, gun rights, and h

Re:Mod Parent Down by grupo-xenon · 2004-04-24 18:59 · Score: 1

From the article:

The zero-day type of exploit is discovered, not as part of the security research process, but when an active exploit is using a vulnerability the software developer was previously unaware of. Many different groups at that point rush to reverse-engineer the exploit to document the vulnerability. Antivirus vendors compete to be first to announce a method to detect and fix the exploit, and the software vendor must devise and release a patch immediately to combat the exploit.

This was in the paragraph RIGHT AFTER the paragraph you quoted.

Easy way to "debunk" someone:
1) Say they said something they didn't say
2) Discredit the assumption
3) Then say (*tada*)

you get the patch quick.... by zogger · 2004-04-13 11:00 · Score: 1

... but not the key. A significant time passes,(whatever, one day, week, I dunno) long enough that everyone who is going to get the patch has downloaded it and is ready to activate it, then everyone gets the unlock key all at once. Instead of systems getting patched piece meal over time, you'll have a huge spike of patched systems, which will be a large enough critical number that any worm won't do much..

that's how I understood it anyway. Seems more or less reasonalbe, certainly different from the other ways I have read and the usual debate of "release as soon as possible and make it public and no, wait forever and keep it a secret"

His approach appears to do both, effectively (theory, I don't think it's been done before)

I can see a coupla probs with it, namely, cracking the key, second, if the virus worm is an inside job to the app company or OS company or security company. Then it won't matter, an uber virus able to beat the patch will be written before the first virus or sploit is released obviously.

Besides that,it sounds reasonable.

False premise by Alex+Belits · 2004-04-13 11:31 · Score: 2, Insightful

The code exploiters use the same tactics against the software vendors that the software vendors and antivirus companies use on them. They wait until the patch for the vulnerability is released, then they reverse-engineer the patch. This is orders of magnitude easier than finding the vulnerability directly.

This is wrong, and therefore the whole article based on this premise is nonsense.

Most of the security flaws are found ransomly or through testing and observation of running software, by various people outside the companies that produce the patches. So the possibilities are:

A black hat hacker/cracker found the vulnerability. Then the exploit is soon to follow, and only after the exploit is found, the fix can be issued. Without any doubt, this has to happen as soon as possible because it will reduce the harm caused by exploit.
A security researcher or regular user found a vulnerability. Then he will follow an established procedure of notifying the vendor and waiting for some reasonable time for the fix to be issued, and after that he may publish a detailed explanation of the nature of vulnerability. This is by far the most common kind of situation -- just look at Bugtraq. Then unless the vulnerability is discovered independently, black hats won't start the work on exploits until at least the patch is ready (and then they will just have to look at what is patched -- no real need for any complex reverse-engineering), but most likely until the explanation of the vulnerability is published (and then only very lazy users are supposed to keep running the unpatched versions). The timing of the patch release is absolutely irrelevant for this case, the clock starts ticking at the moment when the evidence of vulnerability reached black hats, and stops when all the users get the patch. Will it happen sooner or later is irrelevant, but delaying the patch increases the probability of independent discovery, and then back to the case 1, so the sooner is the patch released, the safer the users are.
Same as above but the company managed to delay the release of the patch beyond any reasonable time. Then the person who discovered it may publish the vulnerability description, in hope that then it will be fixed. Will it be out of concern for the users (why are likely to be hit by an exploit if this vulnerability is found independently), or for himself (a user may rely on the software, and afraid that he will be attacked in case of independent discovery by black hats), or as an attempt to shame the company into fixing things faster in the future, or out of plain frustration of dealing with uncoperative vendor, it does not really matter -- vendor should react as soon as possible in either case.
Same as above but the description is published immediately by an uncooperative user/researcher. Needless to say, delays are even more dangerous then.

So the conclusion is: there is no possible scenario that justifies the delays of the patches release. Only a lazy software vendor may think of such a lame excuse for delays.

--
Contrary to the popular belief, there indeed is no God.

didn't you guys get the memo? by Anonymous Coward · 2004-04-13 11:35 · Score: 0

You should have gotten it, it was supposedly sent to all divisions. Our crack audit team discovered that the "evil bit" tends to congregate inside of projects with the "22" suffix appendage.

so, don't do that mkay? Pick another number ,"1" just plain old one seems to work well,M-1,worked great, or the A-1,kicked boo-tay, decent systems, but 22? Doomed to failure and cost over runs and dandruff and gremlins and other nasties. How about "X" that's a nice "power" number lately. xTremE F-1, There ya go,carry on, happy motoring!

Karma Whore. by Anonymous Coward · 2004-04-13 13:38 · Score: 0

Posting this without using AC is a blatant karma whoring activity. I hope you are modded down.

Apple does NOT charge for security fixes by DavidinAla · 2004-04-13 14:17 · Score: 1

No, Apple does NOT charge for security patches and bug fixes. (Of course some people argue that OS X 10.0 should have been a beta, so paying for 10.1 was sort of like paying for bug fixes.)

Patches and point upgrades are free, but the numbering system is different from what you might be used to. For instance, Jaguar was called 10.2 and the next major update a year later (called Panther) was called 10.3. (That jump was similar to going from Win 2k to XP, just for comparison purposes.) However, we're up to 10.3.3 right now, and those updates (along with patches to various other Apple software) are freely available through the built-in software update system. It is simple, painless and effective -- and free.

Not disclosing the problem... by Anonymous Coward · 2004-04-13 16:41 · Score: 0

This article starts with the implicit assumption that no one will describe the problem publicly before a fix is written. And the only way to get the description is to read the patch.

This just goes to show that any description of a patch is readable and that attempts at security through obscurity don't work. Why are people hiding the code again?

The numbering system by TheInternet · 2004-04-13 22:37 · Score: 1

Actually don't they make you pay for your patches?

No. People get confused because of the number system.

"Jaguar" 10.2 = Mac OS X 2.0
"Panther" 10.3 = Mac OS X 3.0

These are major releases with substantial new features that come out once per year.

10.2.1 - 10.2.x are free updates
10.3.1 - 10.3.x are free updates

These are usually bug fixes. There are also security updates and patches to various included apps and components which are also free.

I actually have a packing slip from Apple that says "Mac OS X 1.0", but I guess they decided to go with the other system.

- Scott

--
Scott Stevenson
Tree House Ideas

Re:This will tick off C++ programmers but... by Anonymous Coward · 2004-04-14 00:58 · Score: 0

Also known as a denial of service attack.

No, Pascal does not solve the problem. Lisp or ADA may or may not do, but since noone knows those languages, noone can argue that they do.

looking from a wrong perspective by john_uy · 2004-04-14 02:52 · Score: 1

we are looking things from a wrong perspective. the point mentioned is not entirely accurate but it does make some point.

i would like to emphasize that we cannot avoid vulnerabilities. no matter how much open it becomes, people will miss it. but, we can lessen the damage done from defective patches and exploits.

there is no rule that applies to all.

i have seen some posts regarding releasing everything on tesday. that's both good and bad. good because it reduces the complexity of keeping up with the system especially if you are in a big enterprise scenario maintaining multiple software in multiple platforms. bad because an exploit may already exist and delays to the patch can cause compromise.

maybe all software vendors can produce a regular cycle that is followed by all (i'm dreaming now.) exploited issues may be issued with patches immediately. regular cycles allows for better patch testing and management. exploited items may be reduced as patches as issued immediately but with subject to risks.

since most exploits are network related, maybe someone can device a patch that does not directly modify the file but a patch that intercepts the data coming to it. for example, there is a vulnerability in apache. apache can release a software wherein another program listens on the defined port (of usual 80 but others will still be able to adjust) and it will cut off any damaging traffic before being passed to the actual software (ala hybrid intrusion detection and firewall.) after full testing of the software, the sniffer will be removed the actual file patched. by this, a lot of network related problems will be removed because infection in the network will be eliminated for those who installed the sniffer. it does not break the operation of the application. :)
john

--
Live your life each day as if it was your last.

No clue by sad_ · 2004-04-14 08:23 · Score: 1

again this person has no clue. his argument is that the exploits found in the wild are the result of 'hackers' who interprete and write an exploit on the information found in the security alert released by the software company.

according to this guy security holes are never found outside of the company doing internal audits. this is wrong in so many ways...
if this is true, you don't have to slow down the patch release cycle, you just don't release patches anymore, because as long as you don't nobody knows about it anyway.

--
On a long enough timeline, the survival rate for everyone drops to zero.

Re:His idea, explained so even slash posters can u by grupo-xenon · 2004-04-24 12:12 · Score: 1

Ah, yes, more conspiracy theories.

The article never said "Paid subscription" -- the subscription scheme is only necessary so the patch management system has a way to determine that an optimum number of systems now have the patch in place before distributing the keys and in fact shouldn't be a "paid" system. Some people might NOT want to subscribe, however, because they don't want the vendor to know they are using the software(for whatever reason).

The "stunning hole in the logic" doesn't exist -- the subscriber/non-subscriber patch is same, source can even be included in it. But as many systems as possible are patched immediately upon release of the keys and the OPEN patch is released at the same time as the keys.

There is no patent application on the method -- the publication of the method is a way to introduce it as prior art to prevent someone else from successfully patenting it and allowing any group wanting to distribute secure patches to use it. The subscriber patches only remain secure until the keys are released which actually should be in hours or days (not weeks) depending on the user population size, size of the patch itself, and the vendors network infrastruture available for patch distribution. MEDIAN TIME for a system to be patched would vastly DECREASE.

Slashdot Mirror

Slow Down the Security Patch Cycle?

302 comments