Archive for the ‘Disclosure’ Category
Max Caceres | July 1st, 2008 | Filed Under: Development, Disclosure
A bit over a week has now gone by after critical vulnerabilities in ruby’s runtime were announced and a couple of interesting developments occurred:
The new official ruby releases which include patches for the vulnerabilities actually break critical functionality. In fact, some of the most popular ruby frameworks segfault with any of these releases.
It turns out that the breakage brought by the new releases is not due to the security fixes for Drew Yao’s vulnerabilities, but to other changes that were merged into each release’s branch.
No response or timeline from ruby’s maintainers to produce a good release has been made public.
In an attempt to provide a workable middle ground, third-parties create their own patches, and so do distributors. Some start from a patched release and then work back through the changes until tests pass, others take the opposite approach and start with a last “known-good” release against which they apply selected patches to plug the security holes. Needles to say, the results of each approach are not equivalent.
Developers relying on any of these frameworks are then faced with a difficult choice: wait an indeterminate amount of time for a good release from the official maintainers (and remain vulnerable in the meantime), or apply a patch from a third-party which may not plug all the security holes, or may include unforeseen bugs. This is clearly a problem. In the meantime maintainers have to scramble to get ruby back to a good state that actually plugs the holes while people complain. Everyone loses.
To some extent this is the other side of security response we sometimes advocate for and now we got a taste of: we want our patches and we want them now! And we got them, but our apps don’t work.
The beauty of open-source is not just that we get stuff for free but that we also get a privileged view into the processes around building and maintaining wildly popular software. This is a great opportunity for us as both security and software people to look into why these processes failed and hopefully learn something. Here are my top 3 takeaways:
Keep a “last-known-good” branch to apply critical patches to. The fact that patches had to be applied to unreleased versions of the code means that it is impossible to measure the impact of the change. IMHO this is the single most important mistake behind this state of affairs. This is almost akin to not using version control. Security problems will pop up unpredictably outside of any planned release schedule, and often require a rapid response. End-users may not be able to afford upgrading to a release with new features and even bug fixes every time this happens. It is then highly desirable that a new release which only includes the necessary security patches is made available, to minimize the risk of getting pwned by a new bug or some defiant kid. Are you ready to release critical patches to all the deployed versions of your software even as you are working on its next version?
Open line of communication with your community. It is hard to believe that passing Rails’ tests isn’t an acceptance requirement for every Ruby release, since Rails is the driving force behind Ruby’s adoption. The success of any platform depends on the applications it supports, without the apps the platform doesn’t matter. Microsoft learnt this a long time ago, and that’s why you’ll see them test third-party apps with new releases and security patches, even though technically is not their responsibility. Who are the relevant members of your community? Are you involving them in your release process?
Be more open about vulnerability details. When the vulnerabilities were originally announced very few details were made available (CVE entries for the vulns have been updated with more details since then, though there’s still no entry for the Bignum bug). Because ruby is an open-source project anybody can go and access their source control system to figure out what was actually patched. The fact that you can should be no news to readers of this blog, as people have been doing the same with binary patches for quite some time. Having direct access to not only source but the full source control system is a luxury! Given that the official release didn’t work it was important to isolate the security fixes, and to easily test if 3rd party patches were effective against the flaws. In fact, one of the test cases showed that the official release missed one of Drew’s patches. Lack of details just made it harder for the people trying to help. Do you have a policy about disclosing vulnerability details in your software? Would partners and customers have enough information to evaluate the impact of your patch to their infrastructure?
Just yesterday Apple released a security update which includes fixes for the ruby vulnerabilities. The patched build appears to deal correctly with all test cases, including the string concatenation case, and with Rails’ tests. The official ruby downloads still have issues with both.
12 Comments
Thomas Ptacek | June 26th, 2008 | Filed Under: Disclosure
Editor’s note: I wrote this over 10 years ago, after an aggressively
bad experience reporting problems in Ascend routers. Everything in
here has happened. The original URL for this essay broke long ago,
and I felt like giving it a new home.
Anyone in the software industry knows that it’s much harder to build a
system than it is to tear them down (ignore what those tree-hugging
hippy cryptographers say; these are the same people who want you to
give your source code away for free!). So why is it that security bug
reports get so much more publicity than your press releases about new
product features? Probably because you’re mishandling bug reports!
Know what the pros know; don’t let security problems get out of
hand. The following 10 tips should help you contain and control
security problems.
For examples of how real software companies employ these techniques in
their daily business, simply jump over to CNet’s NEWS.COM and search
for stories with the words “security” and “flaw” in them. See how
simple and effective these real-world strategies are. Remember: your
company pays for every letter of publicity it obtains. Don’t let
childish hackers get a free ride at your expense.
1. Deny Everything
Never, ever admit that there’s a problem. When you receive a bug
report, discredit the report. Did the report come from a competitor?
Bias! Slander! Remember: if 99 percent of your customers can’t
reproduce the problem, 99 percent of your customers won’t be able to
disprove you when you say the problem doesn’t exist. Remember handy
key phrases: “that’s not a bug, it’s a feature!” and “the product was
NEVER designed to handle that!”.
2. Keep It Secret
Bury the report. Inform the reporters that the problem will take
months to fix, or that the fix can’t be released until all your
products are sent back through regression testing. Remind them how
irresponsible it would be to announce a problem for which there is no
fix. Congratulate them for their cleverness and assure them there
there is no way any evil crackers will ever find the problem
themselves. If all else fails, bribe.
3. Forget The Report
Route the bug report to level-1 technical support. For best effect,
ensure that the support technician assigned to the problem speaks
minimal English. Delete the report from your bug tracking system. When
the reporters give up on you and announce publically, claim you never
heard about the problem, and inform the press and your customers that
the reporters are simply seeking publicity. Proceed directly to step
1.
4. Make Excuses
Blame the operating system. Make sure your customers realize that the
problem would never have occurred if Windows 95 popped up a modal
dialog asking users if they’d like to wipe their swap file and start a
new one every time a program exits. Blame the network. Make sure the
press knows that the problem will never, ever occur on “real”
networks, where only well-formed web traffic is passed through the
packet filters. Blame the reporter. Remember handy key statement:
“what was once an obscure problem is now a widely-known problem that
hackers can use”.
5. Downplay
Make sure your customers know every limitation of the security problem
being reported. If the bug lets attackers read any file, remind your
customers that attackers can’t use it to reformat hard drives. If the
attack is complicated, make sure your customers know that it would
take an evil genius to exploit the problem, and that it isn’t a
problem for anyone in the real world. If the press calls, be ready to
inform them that nobody is known to actually be exploiting the
problem, and thus the problem isn’t important.
6. Wait For Next Release
Frequent updates confuse customers. Loads of bug fixes give customers
the impression that your software is less reliable than you know it
really is. Don’t give your customers the wrong idea about your quality
assurance and testing practices… silently roll fixes into the next
release of the software. Added bonus: you can claim “significant
security enhancements” in the advertising for the next version!
7. Beta-Test The Fix
Bug fixes are much easier to produce when you take absolutely no
responsibility for problems caused by the patch. Easier means faster
(not to mention cheaper), and faster is always better when it comes to
security. Tell your customers that you’re acting in their best
interests by getting them a fix as quickly as possible, and that an
official version of the patch will be available soon (see step
6). Save valuable tech support resources by refusing to provide any
assistance for any aspect of your software to customers who have moved
to an unsupported, experimental configuration by installing your
security patch.
8. Patch The Exploit
Capitalize on free quality assurance work by waiting for the exploit
to be released instead of finding and reproducing the problem
yourself. Add “3” to every fixed constant in your source code. Rebuild
software. Try exploit. Repeat until exploit ceases to work. If this
fails to solve the problem, convert all strings in your source code to
Unicode. Rebuild software. Inform customers that you have resolved the
problem.
9. Shoot The Messenger
Anybody who would purposely look for security problems, or tell
someone about a security problem they found “accidentally” (yeah,
right), is clearly a dope-smuggling pedophile. Accuse reporter of
attempting to blackmail your company. From this point on, refer to bug
reporters as “hackers”, as in this statement to concerned customers:
“hackers like these will always be finding problems in software
products, and we will continue to quickly resolve these problems after
notifying the proper authorities.” Remember: the messenger is
expendable. The value of your stock options is not.
10. Threaten Lawsuit
Sneak clause forbidding reverse engineering of your products into your
license. Inform reporter that you believe there could be no way to
find security bugs in your software without violating the license. Too
late to modify license? Accuse reporter of libel, and claim hundreds
of thousands of dollars of damage to your company’s reputation if the
reporter lies to the public about nonexistant flaws in your
software. Remember: it is highly unlikely that anyone who finds bugs
in programs can afford to defend themself in court. Make sure the
reporter remembers that too.
10 Comments
Dave G. | October 30th, 2007 | Filed Under: Disclosure, Industry Punditry
In the past, I have acknowledged QNX and IRIX as security manatees for their complete lack of effort around local security.
iDefense released seven, count them, seven local privilege escalation vulnerabilities in AIX today. Four of them are actually stack overflows. Yes, you heard me, stack overflows. One of them is actually in ftp. Another one is in dig. Yes, dig is setuid root on AIX.
Is there anyone that can actually explain to me why dig and ftp are setuid root executables?
Reader ‘Loic.’ commented:
The reason why “ftp” (but also “host”, “telnet”, “dig”, etc.) are setuid root on AIX is that these binaries use the AIX “system audit” functions (’auditproc()’ et al.) which require root privilege.
This is insane but is nothing new, it was already that way in AIX 4 (~8 years ago).
If the setuid bit is removed from the binaries, they just plain stop working (with no error message).
13 Comments
Thomas Ptacek | August 22nd, 2007 | Filed Under: Disclosure, New Findings
RSnake discovers that Google gadgets can be coerced into
rendering arbitrary Javascript tags, and reports it to Google.
Google responds, in effect, “that’s one of the reasons why they
live under gmodules.com”, continuing, “If you do find a way of
executing this code from the context of a google.com domain,
though, please let us know.”
RSnake decries a “slap in the face”, saying “Google needs to figure
out what XSS is used for”. Attackers can set up phishing
sites on “Google-branded domains”.
Um, RSnake.
Phishers can create “Google branding” on any site they
want. That “Google branding” is just a GIF. Pretty sure
Javascript anywhere can put it on the screen.
That same “vulnerability” appears to be present on Blogspot.
Presumably, on Typepad, Livejournal, and Wordpress as well.
Last time I saw a Bank of America phish, the logo wasn’t
drawn in Windows Paint. I didn’t blame Bank of America.
Likewise, I’m not sure it’s hard for phishers to find or
create infected domain names that start with the letter ‘g’.
What, exactly, do you want them to do? I like your stuff and all that,
and if it’ll make you happy, I’ll bribe Dave to give you a Pwnie for
“best Google hack” over this —- but, am I wrong about this? Or are you?
19 Comments
Dave G. | July 6th, 2007 | Filed Under: Disclosure
Dark Reading reports that Wabisabilabi is open for business as the first public auction site for vulnerabilities.
From the time I was young, my father would tell me this story about how there was a city that was having a city planning problem. The planning committee worked on the problem and couldn’t come up with a solution. One day, someone said they had the solution to the problem and would gladly tell the city for 1,000,000$. The city refused, but by simply knowing that there a solution, they took another crack at it and eventually found a way to solve the problem. Please believe me that my dad tells this story in a way that is more more compelling, but you get the basic idea.
Vulnerability markets can be like this, except it is a problem people didn’t even know that they had. For example, here is a screen capture:
Now, GPG plugin is a small amount of PHP code (< 10,000 SLOC). How long do you think it will take for someone with reasonable skill to find out where the bug is? I promise you, it won’t take long. Let alone this guy, who would find it if someone were transferring the source via a WiFi connection near him. Now a retail price of 1000$EU might be worth it, but I guarantee you that this bug is burned just because the title gives away enough for someone to do a code review and find that (and whatever else lurks in there).
Now competitive researchers, the vendor and/or potential buyers can just go and find the vulns themselves.
12 Comments
Jeremy Rauch | June 12th, 2007 | Filed Under: Apple, Disclosure
[Interesting Discussion In Comments -daveg]
Its no secret: I’ve advocated “responsible disclosure” for years. I
don’t buy that vulnerability research, and discourse about findings,
is why there are so many security problems. Keeping our heads in the
sand won’t improve the situation.
Apple’s recent release of Safari for Windows spurred people in our
community to start looking for its flaws. Great. I say Safari, for all
its good qualities (it’s quick, looks nice, and claims to render more
accurately than other browsers), hasn’t benefitted from
the scrutiny IE or Firefox gets. If people spend time looking at it, finding
vulnerabilities, and reporting them back to Apple, we could have
something here. That a large portion of its open sourced makes it all the better.
I’ve been finding vulnerabilities for over 10 years. I’ve been
frustrated by vendors that resist patching flaws. And I’ve seen
serious flaws go unfixed, due solely to vendor apathy, on numerous
occasions. I can see how that could make someone question the
“responsible” side of disclosure. Are we wasting our time “playing
nice” with vendors?
One of the things we codified when we started Matasano was a
disclosure code of ethics. Part of it applies today. In spite of the
bad vendor experiences we’ve all had, individually and as group, we
felt strongly that to research vulnerabilities without keeping vendors
in the loop wasn’t something that we could participate in.
In fact, we’ve gone one step further. We won’t release information
without a vendor patch being available. We’re just not comfortable
deciding how you should manage your risk. I’d like to keep
thinking that disclosure is about making software safer, and not just
about ego and marketing.
And that’s why, after my blog hiatus/hibernation/avoidance, I’ve
decided to post again.
I say, have all the hostility you want towards Apple. Apple may have
done Dave Maynor wrong. Dave may be justified in carrying a grudge. I
don’t know all of the facts there, and at the moment, it doesn’t look
like any of us will. But I hope Dave, and all the other people taking
shots into the barrel of fish that is Safari, are going to do their best
to deal responsibly with Apple. I’ve found the Apple security folk
I’ve met to be well intentioned and concerned, even if they are severely
overburdened and understaffed.
But Dave, if you’re not going to keep Apple in the loop, and you are
going to harbor secret Safari vulnerabilities that only your company
and your customers and whoever your customers talk to and whoever ever
manages to break into those customers may be, can I ask a favor? Can
you post what your code of ethics is? A lot of us would like to
know. We could show a spectrum, from Errata on the “left”, through
MoXB, to eEye on the “liberal”, Matasano on the “centrist”, ISS on the
“conservative”, and Cisco on the “right wing”.
48 Comments
Thomas Ptacek | June 6th, 2007 | Filed Under: Defenses, Disclosure, Uncategorized
Disclaimer: Matasano has a code of ethics. But it only
says we can’t BE evil. It doesn’t say we can’t TALK ABOUT evil.
Patents are a crappy way to lock up the fix for a vulnerability. 10
years from now, it’s vanishingly unlikely that your discovery will
still be relevant. If it is, you’ve got better things to do with it
than sell it to bottom-feeders.
Here’s a better idea: copyright law. Copyright is immediate.
Here’s what you do:
Find a vulnerability —- anything; say, memory corruption in some OS
service —- and devise a third-party patch for it.
Publish the patch. Only the patch.
But before you do, wrap the patch up in a DRM scheme. An in-kernel,
interrupt-hooking virtual machine with an encrypted instruction set
should do nicely. It’s worth the work; you’ll be doing this over and
over again. You want people to sweat to figure out how your patch works.
Alert the world to your discovery. You’re a hero! You can root any
computer on the Internet!
Don’t publish the details of the vulnerability. No, wait, don’t even
allow the details to be published. If anyone figures out how your
patch works, sue them under the DMCA. Especially if it’s the vendor.
The vendor will, of course, claim they have the right to
reverse-engineer your “intellectual property” for security and
interoperability purposes. Let the courts decide. In the mean time:
nice of them to establish some precedent.
Points to anyone who can prove to me that this doesn’t qualify as “responsible disclosure”.
12 Comments
Dave G. | May 25th, 2007 | Filed Under: Apple, Disclosure
Just wanted to quickly get my thoughts out on the latest OS X update. My rating system is sniff test based as well as how I evaluate risk for me. One day I will actually rate these things based on something more concrete. If you disagree with something or I got it wrong, just add a comment.
HIGH-RISK VULNS
iChat
CVE-ID: CVE-2007-2390
Available for: Mac OS X v10.3.9, Mac OS X Server v10.3.9, Mac OS X v10.4.9, Mac OS X Server v10.4.9
Impact: An attacker on the local network may be able to cause a denial of service or arbitrary code execution
Description: A buffer overflow vulnerability exists in the UPnP IGD (Internet Gateway Device Standardized Device Control Protocol) code used to create Port Mappings on home NAT gateways in iChat. By sending a maliciously crafted packet, an attacker on the local network can trigger the overflow which may lead to an unexpected application termination or arbitrary code execution. This update addresses the issue by performing additional validation when processing UPnP protocol packets in iChat.
mDNSResponder
CVE-ID: CVE-2007-2386
Available for: Mac OS X v10.4.9, Mac OS X Server v10.4.9
Impact: An attacker on the local network may be able to cause a denial of service or arbitrary code execution
Description: A buffer overflow vulnerability exists in the UPnP IGD (Internet Gateway Device Standardized Device Control Protocol) code used to create Port Mappings on home NAT gateways in the OS X mDNSResponder implementation. By sending a maliciously crafted packet, an attacker on the local network can trigger the overflow which may lead to an unexpected application termination or arbitrary code execution. This update addresses the issue by performing additional validation when processing UPnP protocol packets. This issue does not affect systems prior to Mac OS X v10.4. Credit to Michael Lynn of Juniper Networks for reporting this issue.
THIS IS THE REASON YOU NEED TO UPGRADE
Especially if you use a laptop and/or associate to non-friendly networks (e.g. Hotels, Coffeeshops, Anywhere within 50 miles of Dino Dai Zovi). These two bugs look related (probably some cut and paste action :)). My bet is Mike Lynn reported the bug after finding it during PWN2OWN, Apple did a quick check and found the bug in iChat as well.
CoreGraphics
CVE-ID: CVE-2007-0750
Available for: Mac OS X v10.4.9, Mac OS X Server v10.4.9
Impact: Opening a maliciously crafted PDF file may lead to an unexpected application termination or arbitrary code execution
Description: An integer overflow vulnerability exists in the handling of PDF files. By enticing a user to open a maliciously crafted PDF file, an attacker could trigger the overflow which may lead to an unexpected application termination or arbitrary code execution. This update addresses the issue by performing additional validation of PDF files. This issue does not affect systems prior to Mac OS X v10.4.
This looks like a clientside remote. Go to a website and download a PDF and boom.
MEDIUM RISK VULNS
PPP
CVE-ID: CVE-2007-0752
Available for: Mac OS X v10.4.9, Mac OS X Server v10.4.9
Impact: A local user may obtain system privileges
Description: An implementation issue exists in the PPP daemon when loading plugins via the command line, which allows a local user to obtain system privileges. This update addresses the issue through validation of user privileges. This issue does not affect systems prior to Mac OS X v10.4. Credit to an anonymous researcher working with the iDefense VCP for reporting this issue.
VPN
CVE-ID: CVE-2007-0753
Available for: Mac OS X v10.3.9, Mac OS X Server v10.3.9, Mac OS X v10.4.9, Mac OS X Server v10.4.9
Impact: A local user may obtain system privileges
Description: A format string vulnerability exists in vpnd. By running the vpnd command with maliciously crafted arguments, a local user can trigger the vulnerability which may lead to arbitrary code execution with system privileges. This update addresses the issue by performing additional validation of the arguments passed to vpnd. Credit to Chris Anley of NGSSoftware for reporting this issue.
Some solid local (user->root) privilege escalation attacks. Chris Anley is one of those security rockstars that more people should know about. Has one of the best talent to ego ratios in the industry!
LOW RISK VULNS
BIND
CVE-ID: CVE-2007-0493, CVE-2007-0494, CVE-2006-4095, CVE-2006-4096
Available for: Mac OS X v10.3.9, Mac OS X Server v10.3.9, Mac OS X v10.4.9, Mac OS X Server v10.4.9
Impact: Multiple vulnerabilities in BIND, the most serious of which is remote denial of service
Description: BIND is updated to version 9.3.4. Further information is available via the ISC web site at http://www.isc.org/index.pl?/sw/bind/
Yeah… This isn’t going to keep me up at night, but interesting to note that some of these vulnerabilities date back to 01-31-2007 (according to ISC).
Alias Manager
CVE-ID: CVE-2007-0740
Available for: Mac OS X v10.3.9, Mac OS X Server v10.3.9, Mac OS X v10.4.9, Mac OS X Server v10.4.9
Impact: Users may be misled into opening a substituted file
Description: In certain circumstances, an implementation issue in Alias Manager will not show identically-named files contained in identically-named mounted disk images. By enticing a user to mount two identically-named disk images, an attacker could mislead the user into opening a malicious program. This update addresses the issue by performing additional validation of mountpaths. Credit to Greg Bolsinga of Blurb, Inc. for reporting this issue.
crontabs
CVE-ID: CVE-2007-0751
Available for: Mac OS X v10.3.9, Mac OS X Server v10.3.9, Mac OS X v10.4.9, Mac OS X Server v10.4.9
Impact: The daily /tmp cleanup script may lead to a denial of service
Description: Filesystems mounted in the /tmp directory may be deleted when the daily cleanup script is executed, which may lead to a denial of service. This update addresses the issues by updating the daily cleanup script to prevent find commands from descending into mounted filesystems.
fetchmail
CVE-ID: CVE-2007-1558
Available for: Mac OS X v10.3.9, Mac OS X Server v10.3.9, Mac OS X v10.4.9, Mac OS X Server v10.4.9
Impact: fetchmail password disclosure may be possible
Description: fetchmail is updated to version 6.3.8 to address a cryptographic weakness that could lead to the disclosure of fetchmail passwords. Further information is available via the fetchmail web site at http://fetchmail.berlios.de/fetchmail-SA-2007-01.txt
file
CVE-ID: CVE-2007-1536
Available for: Mac OS X v10.3.9, Mac OS X Server v10.3.9, Mac OS X v10.4.9, Mac OS X Server v10.4.9
Impact: Running the file command on a maliciously crafted file may lead to an unexpected application termination or arbitrary code execution
Description: A heap buffer overflow vulnerability exists in the file command line tool, which may lead to an unexpected application termination or arbitrary code execution. This update addresses by performing additional validation of files that are passed to the file command.
ruby
CVE-ID: CVE-2006-5467, CVE-2006-6303
Available for: Mac OS X v10.3.9, Mac OS X Server v10.3.9, Mac OS X v10.4.9, Mac OS X Server v10.4.9
Impact: Denial of service vulnerabilities in the Ruby CGI library
Description: Multiple denial of service issues exist in the Ruby CGI library. By sending maliciously crafted HTTP requests to a web application using cgi.rb, an attacker could trigger an issue which may lead to a denial of service. This update addresses the issues by applying the Ruby patches.
screen
CVE-ID: CVE-2006-4573
Available for: Mac OS X v10.3.9, Mac OS X Server v10.3.9, Mac OS X v10.4.9, Mac OS X Server v10.4.9
Impact: Multiple denial of service vulnerabilities in GNU Screen
Description: The screen command line tool is updated to address multiple denial of service vulnerabilities. Further information is available via the GNU web site at http://lists.gnu.org/archive/html/screen-users/2006-10/msg00028.html
texinfo
CVE-ID: CVE-2005-3011
Available for: Mac OS X v10.3.9, Mac OS X Server v10.3.9, Mac OS X v10.4.9, Mac OS X Server v10.4.9
Impact: A vulnerability in texinfo may allow arbitrary files to be overwritten
Description: A file handling issue exists in texinfo, which may allow a local user to create or overwrite files with the privileges of the user running texinfo. This update addresses the issue through improved handling of temporary files.
A couple of not so interesting local vulns. Unlikely to impact more Mac users as they require you to either use tools not often used by most Mac users, and/or require a malicious file dropped on the filesystem that the victim will have to run said command against.
5 Comments
Dave G. | May 25th, 2007 | Filed Under: Disclosure
I reported a vulnerability on a website developed by a popular Web 2.0 company. As it happens, we are a paying customer, so I really want them to take it seriously.
I will now post an anonymized version of the conversation:
Step #1: I send in a vulnerability report. I explain the vulnerability in a concise email and include repro steps.
They reply:
Thanks for the tip, David. It’s been noted.
I reply:
Can you give me some guidance on your response guidelines to
security vulnerabilities? Is there a timeframe that you try and
have vulnerabilities fixed by?
They reply:
Hi David,
We’re always looking for new ideas and fixes to roll out in future
updates but as as rule we don’t comment on possibilities or
timeframes.
I reply:
How will I know when this vulnerability is fixed?
They reply:
Actually, they don’t reply at all.
16 Comments
Dave G. | May 7th, 2007 | Filed Under: Disclosure
I like this one.
On March 23rd, Patrick Webster reported a vulnerability to WebMethods. He never heard back so he posted the advisory publicly on April 11th.
On April 17th, WebMethods wrote what was basically an interim advisory, where they:
Thanked him for reporting the vulnerability.
Posted workarounds prior to a patch being available (potential workarounds included disabling the component, requiring authorization and chroot).
Gave a time by which they thought the patch would be available.
Today, WebMethods released an updated advisory with patch information. It wasn’t released on the date specified in the interim advisory, but all things considered, they did a lot of things I liked.
Even though they didn’t respond to the initial advisory and they were a week later than the time they specified in the interim advisory, I really liked that they got an interim advisory out. Too many companies leave customers twisting in the wind when a zero day gets disclosed. Also, including when they were going to communicate next was smart, even if they missed the date.
Everyone makes mistakes during the disclosure process. It’s how you handle your mistakes that counts.
2 Comments
