Re: [Full-disclosure] Re: what we REALLY learned from WMF
Hi:I think it would be good if Microsoft releases patches a la opensource. But I think since M$ does the whole thing is their decision after all to do it one way or another. I understand that sometimes is a matter that customers have no other choice than take things as they decide. The normal answer would be fine don't use my systems and they would be right on the other side you can't stop using their systems. Ahhh but then there are other ppl that realized the whole trick and started to take action since 1995 and will let you take action too ;). Take a look at this website [ http://www.reactos.com ] and start to taste our freedom in an alpha stage but close to beta. And yes I hope to get an avalanche with this since I'm tired of huge downloads, tons of closed information huge amounts of non documented stuff, licensisng issues, limits on the number of connections no more RAW sockets and a tons of more stuff that makes a big chain in my neck and tons of other more ppl. Some of this chains were set up even before I was born. So I guess that I as a number of more ppl really had no chances. I expect to break them some day and surely not alone. In that case I could say that maybe I really was alive and in this world. RegardsWaldoOn 1/6/06, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote:Gadi Evron < [EMAIL PROTECTED]> wrote on 01/05/2006 04:53:45 PM:> 2. Microsoft decided to jump through a few QA tests this time, and> release a patch.>> Why should they be releasing BETA patches? > If they do, maybe they should release BETA patches more often, let those> who want to - use them. It can probably also shorten the testing period> considerably.> If this patch is not BETA, but things did just /happen/ to progress more > swiftly.. than maybe we should re-visit option #1 above.>> ...>> Maybe it?s just that we are used to sluggishness. Perhaps it is time we,> as users and clients, started DEMANDING of Microsoft to push things up a > notch.>> ...>> Put in the necessary resources, and release patches within days of first> discovery. I?m willing to live with weeks and months in comparison to> the year+ that we have seen sometimes. Naturally some problems take > longer to fix, but you get my drift.Way to go, Gadi. Nicely put.The opensource guys almost always have different repositories for previewand testing. Ubuntu currently has Dapper available for download and the repositories are available, even though it's not due for release untilApril. Debian has multiple levels of testing platforms, depending on howinsane you happen to be. On the consumer end, many customers will also maintain two repositories. One for production, the other to test whatthey're about to push out.While Microsoft doesn't open their code to the world early, they couldselectively involve key customers which are willing to have a couple of their PC's run with a different update site. A"test.windowsupdate.microsoft.com" if you will (or the SUS equivalent).Why should the OSS people have all the fun!? ;) Or rather, why should the pay-for customers get the shaft when the freestuff is doing it "More Right".Matt___Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.htmlHosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Re: what we REALLY learned from WMF
Gadi Evron wrote: > > I am not criticizing Microsoft over the patch. I am happy. > > I am just saying that we as an industry got used to False Positives, > slow responses, etc. We should demand more and this situation proved > it is possible. > > Gadi. Ja, all we have to do is write the patch for them, then we have great turn around ;-) Seriously though, I think the fact that someone else duplicated their patch (file date in the patch of the 28th shows this, as well as the bindiff) then they had pre-hotfix-release information on what bugs occured due to the removal of this abortproc wmf "feature" on a very large customer base (300GB of uploads before the site was taken offline, thats a _big_ test user base) was what made it possible for MS to release the patch earlier than promised. Still though, Gadi is right that this shows if there is enough demand for an RC1 patch, they may release them as long as the exploit can be googled beforehand and MS doesnt have to worry about ppl RCE'ing the beta patch and creating an exploit as a result of their program. a lot of "ifs" but it can happen -JP ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Re: what we REALLY learned from WMF
I do know that MS prefers to do extensive testing on patches. ms04-015 , i was told, had to go through over 200 differing infrastructure / product / implimentation testings before release. i am sure some of these test are done for large corps to ensure no breakage across a multitude of architectures, etc. A patch may work properly on 99% of everything, but its that 1% they focus on before formal release. ( esp if that is a large enterprise ) my2bits, MW ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Re: what we REALLY learned from WMF
Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] wrote in news:[EMAIL PROTECTED] > Don't release a beta patch > > 1. it would get patches into reverse engineering faster [hello look what > happened to the leaked patch] That would only matter for issues where there weren't already dozens of public sploits, it's a complete irrelevancy in this particular case. cheers, DaveK -- Can't think of a witty .sigline today ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Re: what we REALLY learned from WMF
On 05/01/06 16:07 -0800, Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] wrote: > > If the security issue has been responsible disclosed, there is a process > that is needed to build a patch and test the patch. Some issues take > more than 'days' sir. And testing takes time as well, sir. > A question for people who find such exploitable bugs and report them upstream. How many days does it take for upstream to patch and release bugfix? It would be nice if you could include the severity of the bug as well. (Vendor and product names, product versions would be nice as well). Quite a few of us generally get to know only when the fix is released. Devdas Bhagat ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Re: what we REALLY learned from WMF
The solution to folks pimping their websites through lists is to obfuscate the URL when doing a "reply" .. eg: http://blogs.shamelesslyplugged.com/index.php/archives/182 Or better yet, don't include the URL at all when replying, only use the relevent bits of the original message. /mike. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Re: what we REALLY learned from WMF
Gadi Evron wrote: What we really learn from this all WMF "thingie", is that when Microsoft wants to, it can. Microsoft released the WMF patch ahead of schedule ( http://blogs.securiteam.com/index.php/archives/181 ) Yep, THEY released the PATCH ahead of schedule. What does that teach us? There are a few options: 1. When Microsoft wants to, it can. There was obviously pressure with this 0day, still — most damage out there from vulnerabilities is done AFTER Microsoft releases the patch and the vulnerability becomes public. 2. Microsoft decided to jump through a few QA tests this time, and release a patch. Why should they be releasing BETA patches? If they do, maybe they should release BETA patches more often, let those who want to - use them. It can probably also shorten the testing period considerably. If this patch is not BETA, but things did just /happen/ to progress more swiftly.. than maybe we should re-visit option #1 above. ... Maybe it’s just that we are used to sluggishness. Perhaps it is time we, as users and clients, started DEMANDING of Microsoft to push things up a notch. ... Put in the necessary resources, and release patches within days of first discovery. I’m willing to live with weeks and months in comparison to the year+ that we have seen sometimes. Naturally some problems take longer to fix, but you get my drift. It’s just like with false positives… as an industry we are now used to them. We don’t treat them as bugs, we treat them as an “acceptable level of”, as I heard Aviram mention a few times. ... The rest is in my blog entry on the subject: http://blogs.securiteam.com/index.php/archives/182 Gadi. Although I agree with a lot of what you have said I do feel that this is a rather shameless way to start what is undoubtedly to become a 'flame-war' and to pimp your own website. Please try to keep bugtraq on target by posting bug related items. Kind Regards, Gavin COnway -- UKS Ltd, Birmingham Road, Studley, Warwickshire, B80 7BG Tel: 08700 681 333 - Fax: 01527 851 301 - AS: 20547 [EMAIL PROTECTED] - www.uksolutions.co.uk ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Re: what we REALLY learned from WMF
Gadi Evron <[EMAIL PROTECTED]> wrote on 01/05/2006 04:53:45 PM: > 2. Microsoft decided to jump through a few QA tests this time, and > release a patch. > > Why should they be releasing BETA patches? > If they do, maybe they should release BETA patches more often, let those > who want to - use them. It can probably also shorten the testing period > considerably. > If this patch is not BETA, but things did just /happen/ to progress more > swiftly.. than maybe we should re-visit option #1 above. > > ... > > Maybe it?s just that we are used to sluggishness. Perhaps it is time we, > as users and clients, started DEMANDING of Microsoft to push things up a > notch. > > ... > > Put in the necessary resources, and release patches within days of first > discovery. I?m willing to live with weeks and months in comparison to > the year+ that we have seen sometimes. Naturally some problems take > longer to fix, but you get my drift. Way to go, Gadi. Nicely put. The opensource guys almost always have different repositories for preview and testing. Ubuntu currently has Dapper available for download and the repositories are available, even though it's not due for release until April. Debian has multiple levels of testing platforms, depending on how insane you happen to be. On the consumer end, many customers will also maintain two repositories. One for production, the other to test what they're about to push out. While Microsoft doesn't open their code to the world early, they could selectively involve key customers which are willing to have a couple of their PC's run with a different update site. A "test.windowsupdate.microsoft.com" if you will (or the SUS equivalent). Why should the OSS people have all the fun!? ;) Or rather, why should the pay-for customers get the shaft when the free stuff is doing it "More Right". Matt ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] RE: what we REALLY learned from WMF
>I am not criticizing Microsoft over the patch. I am happy. >I am just saying that we as an industry got used to False Positives, >slow responses, etc. We should demand more and this situation proved it >is possible. > Gadi. I can live with that As long as we all remember that our demands must also be realistic... ;-) ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] RE: what we REALLY learned from WMF
Actually, what this whole situation proves is that a company with an installed base that figures in, what, the 90th percentile has an incredible amount of testing to do but that a talented individual can create a patch and issue it basically untested with the appropriate disclaimer quite rapidly. In this instance the patch didn't fix the vulnerable code at the source and was truly a "patch". Had MS issued that patch immediately it seems to me that you would have criticised them for putting out a "half-assed" patch. Had they issued their actual patch untested and it broke a couple of percent of their user base's installs you probably would have castigated them for being irresponsible and not testing the patch. What actually occured was that they, as is their policy, issued the best workaround they could, (unreg the .dll), and promised a patch by a certain date. They beat the schedule by what 25%, maybe 50% from the time they made the promise. In any performance evaluation one would have to conclude that MS performed "better than expected". I would agree that not asking for improvement ever would lead to further mediocrity but at the same time, placing anyone in a no-win situation _all_ the time eventually leads to them losing interest. Giving credit where it is due isn't unfair in this situation and in the end you always get more with sugar than you do vinegar. -Original Message- From: Gadi Evron [mailto:[EMAIL PROTECTED] Sent: Thu 1/5/2006 7:12 PM To: Adrian Marsden Cc: bugtraq@securityfocus.com; full-disclosure@lists.grok.org.uk Subject:Re: what we REALLY learned from WMF Adrian Marsden wrote: > This is a silly post What are you trying to prove? That in some cases a > company can test a patch quicker than in others? > > MS understood the issue, promised a fix on their scheduled date and did > better than expected So you criticise them > > Way to go Make it so they can never win then they won't bother... and > we all know who suffers then I may chose MS as an example that companies CAN do better. I believe this "fluke" gave us the perfect example of how security incidents should be handled. Why should we now settle for less? Naturally, each problem has its own issues and time demands. That doesn't change the fact of the matter. Gadi. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Re: what we REALLY learned from WMF
On 06/01/06, Gadi Evron <[EMAIL PROTECTED]> wrote: > I am just saying that we as an industry got used to False Positives, > slow responses, etc. We should demand more and this situation proved it > is possible. I doubt your "industry" had anything to do with it. Someone running a cost-out project probably discovered they could save a few 100k by reducing support requests via call centers and email bandwidth if they dropped it, and in return got themselves a nice PM / consolidation job with an office, a view and a parking space.. -- regards c0ntex ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Re: what we REALLY learned from WMF
Adrian Marsden wrote: Actually, what this whole situation proves is that a company with an installed base that figures in, what, the 90th percentile has an incredible amount of testing to do but that a talented individual can create a patch and issue it basically untested with the appropriate disclaimer quite rapidly. In this instance the patch didn't fix the vulnerable code at the source and was truly a "patch". Had MS issued that patch immediately it seems to me that you would have criticised them for putting out a "half-assed" patch. Had they issued their actual patch untested and it broke a couple of percent of their user base's installs you probably would have castigated them for being irresponsible and not testing the patch. What actually occured was that they, as is their policy, issued the best workaround they could, (unreg the .dll), and promised a patch by a certain date. They beat the schedule by what 25%, maybe 50% from the time they made the promise. In any performance evaluation one would have to conclude that MS performed "better than expected". I would agree that not asking for improvement ever would lead to further mediocrity but at the same time, placing anyone in a no-win situation _all_ the time eventually leads to them losing interest. Giving credit where it is due isn't unfair in this situation and in the end you always get more with sugar than you do vinegar. I am not criticizing Microsoft over the patch. I am happy. I am just saying that we as an industry got used to False Positives, slow responses, etc. We should demand more and this situation proved it is possible. Gadi. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] RE: what we REALLY learned from WMF
Hi Gadi, Anyone who releases software to a demanding customer who is in a hurry knows that quick fixes can sometimes make more problems. While some customers are more understanding than others, many customers are already somewhat disgruntled about there being a problem in the first place. If you don't release a fix immediately, the customer is unhappy. If you rush and miss something, the customer is unhappy. I haven't personally seen any of the problems reported with the unofficial patch from Ilfak Guilfanov, however, if that patch broke anything people should be pretty accepting. He made a great effort to help with the problem, and he did well in his sacrifice of QA for speed. The same goes for any of the other official and unofficial work-arounds that were published. The Guilfanov patch was reported as working and pushed by several top security specialists - some other quick work-arounds didn't do as well. When Microsoft puts out a patch that breaks their OS, people get upset. They are in a damned if we do and damned if we don't on the subject of spending time in QA for this; they are the ones with two options neither of which are pretty. I personally don't want to see a huge push for them to rush rather than trying to do it properly. After a certain point, faster doesn't get you better. Microsoft's security process has improved by leaps and bounds ever since the XPSP2 push. I think we all did demand that they push it up a notch, and we got XPSP2 work and much more default security rather than Longhorn feature work. I would rather see them spend time on security and delay feature releases, so I am glad they decided to change their approach. It is possible that they just threw more resources toward getting this patch out soon in lieu of other deadlines. It is possible they caved to public pressure and just released it half-way through QA. It is possible that they were trying to fix all their end-of-life and old service-pack platforms as well for January 10th and we got a patch for the latest versions five days early instead. It may simply be that they gave themselves some headroom on solving the problem. What if they had promised a fix by the 1st? They may have even truly felt the patch could wait until the 10th. I wouldn't rush to any conclusion yet. We will have to wait to see if this is a good fix. In the meantime, I'd rather think that this is in line with all the effort Microsoft has been putting toward security and security process lately. Give everyone who worked on this and those still working to get the patch tested and installed in their own environment, a pat on the back first. Sincerely, Donald -Original Message- From: Gadi Evron [mailto:[EMAIL PROTECTED] Sent: Thursday, January 05, 2006 4:54 PM To: bugtraq@securityfocus.com Cc: full-disclosure@lists.grok.org.uk Subject: what we REALLY learned from WMF What we really learn from this all WMF "thingie", is that when Microsoft wants to, it can. Microsoft released the WMF patch ahead of schedule ( http://blogs.securiteam.com/index.php/archives/181 ) Yep, THEY released the PATCH ahead of schedule. What does that teach us? There are a few options: 1. When Microsoft wants to, it can. There was obviously pressure with this 0day, still - most damage out there from vulnerabilities is done AFTER Microsoft releases the patch and the vulnerability becomes public. 2. Microsoft decided to jump through a few QA tests this time, and release a patch. Why should they be releasing BETA patches? If they do, maybe they should release BETA patches more often, let those who want to - use them. It can probably also shorten the testing period considerably. If this patch is not BETA, but things did just /happen/ to progress more swiftly.. than maybe we should re-visit option #1 above. ... Maybe it's just that we are used to sluggishness. Perhaps it is time we, as users and clients, started DEMANDING of Microsoft to push things up a notch. ... Put in the necessary resources, and release patches within days of first discovery. I'm willing to live with weeks and months in comparison to the year+ that we have seen sometimes. Naturally some problems take longer to fix, but you get my drift. It's just like with false positives. as an industry we are now used to them. We don't treat them as bugs, we treat them as an "acceptable level of", as I heard Aviram mention a few times. ... The rest is in my blog entry on the subject: http://blogs.securiteam.com/index.php/archives/182 Gadi. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Re: what we REALLY learned from WMF
Don't release a beta patch 1. it would get patches into reverse engineering faster [hello look what happened to the leaked patch] and 2. Don't ask for an untested patch if you are not willing to be there in the newsgroups, communities and listserves helping the dead bodies after a bad patch sir. Do you do/handle change management in your firm? Even in my small firm I could not handle the 'any time/any day' that patches used to come out before. Be careful of what you ask for sir...because if you get what you want ensure your firm has the resources to test/deploy/change management on a 24 hours a day 7 days a week schedule because exploits can be built in less than 20 minutes. If the security issue has been responsible disclosed, there is a process that is needed to build a patch and test the patch. Some issues take more than 'days' sir. And testing takes time as well, sir. For my community I want tested patches sir, and I will argue until doomsday on that point. Don't hurt my community with a bad patch or a beta patch, sir. Susan SBS community member Gadi Evron wrote: What we really learn from this all WMF "thingie", is that when Microsoft wants to, it can. Microsoft released the WMF patch ahead of schedule ( http://blogs.securiteam.com/index.php/archives/181 ) Yep, THEY released the PATCH ahead of schedule. What does that teach us? There are a few options: 1. When Microsoft wants to, it can. There was obviously pressure with this 0day, still — most damage out there from vulnerabilities is done AFTER Microsoft releases the patch and the vulnerability becomes public. 2. Microsoft decided to jump through a few QA tests this time, and release a patch. Why should they be releasing BETA patches? If they do, maybe they should release BETA patches more often, let those who want to - use them. It can probably also shorten the testing period considerably. If this patch is not BETA, but things did just /happen/ to progress more swiftly.. than maybe we should re-visit option #1 above. ... Maybe it’s just that we are used to sluggishness. Perhaps it is time we, as users and clients, started DEMANDING of Microsoft to push things up a notch. ... Put in the necessary resources, and release patches within days of first discovery. I’m willing to live with weeks and months in comparison to the year+ that we have seen sometimes. Naturally some problems take longer to fix, but you get my drift. It’s just like with false positives… as an industry we are now used to them. We don’t treat them as bugs, we treat them as an “acceptable level of”, as I heard Aviram mention a few times. ... The rest is in my blog entry on the subject: http://blogs.securiteam.com/index.php/archives/182 Gadi. -- Letting your vendors set your risk analysis these days? http://www.threatcode.com ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Re: what we REALLY learned from WMF
It's easy for us on this side to Monday morning quarterback and say "oh make it so". There are times too that I go...okay ...come on ...how many days has it taken for that to get fixed? But then again, I don't write code, I don't track back dependencies, I don't ensure umpteem languages still work and all the other interconnectivity between programs and code still function. It's easy to say this stuff on this side but understand that the mere release of a beta patch puts in jeopardy all of the consumer home machines and small businesses that have no admin to protect them and take mitigation measures. What "I" really learned from this is to decide my "OWN" risk tolerance and stop listening to all the sites and blogs and news reports and what not that spread a lot of FUD and misinformation and used this many times as a PR vehicle. Only I know what risk I will tolerate. That's what I learned from this. Susan Gadi Evron wrote: Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] wrote: Don't release a beta patch 1. it would get patches into reverse engineering faster [hello look what happened to the leaked patch] and 2. Don't ask for an untested patch if you are not willing to be there in the newsgroups, communities and listserves helping the dead bodies after a bad patch sir. Do you do/handle change management in your firm? Even in my small firm I could not handle the 'any time/any day' that patches used to come out before. Be careful of what you ask for sir...because if you get what you want ensure your firm has the resources to test/deploy/change management on a 24 hours a day 7 days a week schedule because exploits can be built in less than 20 minutes. If the security issue has been responsible disclosed, there is a process that is needed to build a patch and test the patch. Some issues take more than 'days' sir. And testing takes time as well, sir. For my community I want tested patches sir, and I will argue until doomsday on that point. Don't hurt my community with a bad patch or a beta patch, sir. I quite agree, I disagree on the amount of time it currently takes for any vendor to release patches. Apparently we "Got used" to slowness, false positives and many other ills. Maybe it's time that changed? Gadi. -- Letting your vendors set your risk analysis these days? http://www.threatcode.com ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] RE: what we REALLY learned from WMF
This is a silly post What are you trying to prove? That in some cases a company can test a patch quicker than in others? MS understood the issue, promised a fix on their scheduled date and did better than expected So you criticise them Way to go Make it so they can never win then they won't bother... and we all know who suffers then -Original Message- From: Gadi Evron [mailto:[EMAIL PROTECTED] Sent: Thu 1/5/2006 4:53 PM To: bugtraq@securityfocus.com Cc: full-disclosure@lists.grok.org.uk Subject:what we REALLY learned from WMF What we really learn from this all WMF "thingie", is that when Microsoft wants to, it can. Microsoft released the WMF patch ahead of schedule ( http://blogs.securiteam.com/index.php/archives/181 ) Yep, THEY released the PATCH ahead of schedule. What does that teach us? There are a few options: 1. When Microsoft wants to, it can. There was obviously pressure with this 0day, still — most damage out there from vulnerabilities is done AFTER Microsoft releases the patch and the vulnerability becomes public. 2. Microsoft decided to jump through a few QA tests this time, and release a patch. Why should they be releasing BETA patches? If they do, maybe they should release BETA patches more often, let those who want to - use them. It can probably also shorten the testing period considerably. If this patch is not BETA, but things did just /happen/ to progress more swiftly.. than maybe we should re-visit option #1 above. ... Maybe it’s just that we are used to sluggishness. Perhaps it is time we, as users and clients, started DEMANDING of Microsoft to push things up a notch. ... Put in the necessary resources, and release patches within days of first discovery. I’m willing to live with weeks and months in comparison to the year+ that we have seen sometimes. Naturally some problems take longer to fix, but you get my drift. It’s just like with false positives… as an industry we are now used to them. We don’t treat them as bugs, we treat them as an “acceptable level of”, as I heard Aviram mention a few times. ... The rest is in my blog entry on the subject: http://blogs.securiteam.com/index.php/archives/182 Gadi. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Re: what we REALLY learned from WMF
As I'm not a coder.. I don't have the technical information to answer that one authoritatively. The WMF issue has taught me ...if you aren't an authority on the issueshut up! :-) Gadi Evron wrote: Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] wrote: It's easy for us on this side to Monday morning quarterback and say "oh make it so". There are times too that I go...okay ...come on ...how many days has it taken for that to get fixed? But then again, I don't write code, I don't track back dependencies, I don't ensure umpteem languages still work and all the other interconnectivity between programs and code still function. It's easy to say this stuff on this side but understand that the mere release of a beta patch puts in jeopardy all of the consumer home machines and small businesses that have no admin to protect them and take mitigation measures. What "I" really learned from this is to decide my "OWN" risk tolerance and stop listening to all the sites and blogs and news reports and what not that spread a lot of FUD and misinformation and used this many times as a PR vehicle. Only I know what risk I will tolerate. That's what I learned from this. And only you can decide your own risk vs. gain. Question is though, as I agree with you about BETA patches (although you don't have to use them), is if RELEASE patches can be released a lot faster? This is what this case taught me. Gadi. -- Letting your vendors set your risk analysis these days? http://www.threatcode.com ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Re: what we REALLY learned from WMF
Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] wrote: Don't release a beta patch 1. it would get patches into reverse engineering faster [hello look what happened to the leaked patch] and 2. Don't ask for an untested patch if you are not willing to be there in the newsgroups, communities and listserves helping the dead bodies after a bad patch sir. Do you do/handle change management in your firm? Even in my small firm I could not handle the 'any time/any day' that patches used to come out before. Be careful of what you ask for sir...because if you get what you want ensure your firm has the resources to test/deploy/change management on a 24 hours a day 7 days a week schedule because exploits can be built in less than 20 minutes. If the security issue has been responsible disclosed, there is a process that is needed to build a patch and test the patch. Some issues take more than 'days' sir. And testing takes time as well, sir. For my community I want tested patches sir, and I will argue until doomsday on that point. Don't hurt my community with a bad patch or a beta patch, sir. I quite agree, I disagree on the amount of time it currently takes for any vendor to release patches. Apparently we "Got used" to slowness, false positives and many other ills. Maybe it's time that changed? Gadi. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Re: what we REALLY learned from WMF
Adrian Marsden wrote: This is a silly post What are you trying to prove? That in some cases a company can test a patch quicker than in others? MS understood the issue, promised a fix on their scheduled date and did better than expected So you criticise them Way to go Make it so they can never win then they won't bother... and we all know who suffers then I may chose MS as an example that companies CAN do better. I believe this "fluke" gave us the perfect example of how security incidents should be handled. Why should we now settle for less? Naturally, each problem has its own issues and time demands. That doesn't change the fact of the matter. Gadi. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Re: what we REALLY learned from WMF
Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] wrote: It's easy for us on this side to Monday morning quarterback and say "oh make it so". There are times too that I go...okay ...come on ...how many days has it taken for that to get fixed? But then again, I don't write code, I don't track back dependencies, I don't ensure umpteem languages still work and all the other interconnectivity between programs and code still function. It's easy to say this stuff on this side but understand that the mere release of a beta patch puts in jeopardy all of the consumer home machines and small businesses that have no admin to protect them and take mitigation measures. What "I" really learned from this is to decide my "OWN" risk tolerance and stop listening to all the sites and blogs and news reports and what not that spread a lot of FUD and misinformation and used this many times as a PR vehicle. Only I know what risk I will tolerate. That's what I learned from this. And only you can decide your own risk vs. gain. Question is though, as I agree with you about BETA patches (although you don't have to use them), is if RELEASE patches can be released a lot faster? This is what this case taught me. Gadi. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
