I’ve posted a few times before on vulnerability disclosure:
As you can tell from the titles (I’m not vain enough to think you actually clicked and read any of those), my stance is that public disclosure without vendor (or developer, if you prefer, because not everyone charges for the software they distribute) involvement benefits only the discloser and the criminal hackers who want to download unfixed exploits (zero days). I also agree with Microsoft’s stance that “responsible disclosure” is a term that means only whatever the author wants it to mean at the time he writes it, and that “coordinated disclosure” more accurately reflects the goal of having discoverer work with developer / vendor to provide the best security result, of having a fix or workaround shipped as soon as possible, and with the best chance of it arriving before malicious exploits.
The various vulnerability databases that are used by discoverers when publicising their vulnerabilities certainly don’t help the situation.
First, of course, is the word “various”. That there are several vulnerability databases out there is a classic problem – it is inefficient in the extreme for vendors to read them all, and filter out the duplicates to find only those issues that are unique and new.
Then there’s the reverse angle on “vendors can’t realistically devote the time to read through the multitude of vulnerability databases” – certainly the vulnerability database authors don’t read the vendors’ statements, because each database is littered with reports marked as “unpatched” that have been patched for years. I keep finding new database entries relating to “unpatched” bugs in my own software that were actually fixed several releases – and several years – ago.
It would be rather handy if these databases would communicate with vendors when they are adding an exploit to their database, so that the vendor could respond right back when the issue is fixed. Perhaps what is needed is a filtered feed protocol of some kind, so that a vendor could “subscribe” their applications (perhaps even with version numbers), and could then work off the exploits as they are recorded, assigning them either as “duplicates”, or to a new bin, and thereby automatically send out notices to the vulnerability databases when the flaws are fixed, along with information on how to get the fixes.
Each time I have suggested this, the reception I get back has been rather frosty – as if the vulnerability database owners are happy with the status quo. Since their business model is based on alarming users about their security posture, perhaps that’s not too far from the truth.
Finally, there’s an apparent lack of oversight at many of these vulnerability databases of the vulnerabilities and exploits submitted. “They’ll let anything through” is the sentiment I’ve heard from many of my colleagues in the security world, echoing my own opinion.
Along with the “let anything through”, of course, is the issue of discoverers submitting any old thing, because they know they’ll see their name in (virtual) print. While I can understand the thrill (I do have a blog, after all), I also think that there needs to be a certain level of community involvement which will say “try harder and come back when you have a big-boy post for us”. This is partly the vulnerability database handlers’ fault, but also it’s the fault of the community of discoverers, which seems to be uninterested in the idea of ensuring that the community around them is of high quality. Where’s the dissent? Where are the people asking for better reports, more convincing examples?
As you can imagine, I had to have my own “tipping point” that made me write this post. That point was when I dealt with the report at http://www.exploit-db.com/exploits/12587/ – “WFTPD Server 3.30 Multiple remote vulnerabilities(0day)”, discovered by “fl0 fl0w”. Notice that I didn’t actually receive an email directing me to this vulnerability – discoverer and multiple vulnerability databases simply publicise it without bothering to verify with me that this is a real vulnerability, or to give me a chance to help correct it if it is. Exploit-db, like others, even goes so far as to mark it with a “verified” check mark, so that you know it’s a top-notch vulnerability, really bad stuff.
That title seems like a winner – MULTIPLE REMOTE VULNERABILITIES, and a zero-day, no less. Great, scary stuff, worthy of a reading in Vincent Price’s voice.
Now, let’s have a look at the descriptive text.
Oh, that’s right, there isn’t any – it’s all source code. No problem, I’m a developer, and it’s written in a language I speak.
Fine, so I read the source code, and all I can tell that it does is connect to an FTP server (presumably running WFTPD) at a user-provided address, where it uses a user-provided username and password, to log on. Then it sends the SYST command (presumably so you can verify the information returned), and finally runs either the MKD or DELE command, with user-supplied parameters to make a directory, or delete a file.
So far, all he’s got is a minimalist FTP client, rather than a piece of code specifically displaying a flaw. I could get his code to do a number of things, such as, well, making a directory, and deleting a file.
The comments in the file did suggest that there’s something important about “../” and “../../”, so there’s a hint there of a directory traversal flaw, or “directory transversal” as “fl0 fl0w” puts it.
So, I spend a few hours trying a variety of different traversal attack possibilities, each time coming up empty. Of course, this could simply be due to the old security maxim that of course you can design a security mechanism that you can’t break. The tough part is finding a security mechanism that other people can’t break.
Finally, I manage to find “fl0 flow” – apparently, he goes by “email@example.com”, as well as the more pedestrian “Stefan M”. A series of email exchanges finally makes it clear what his alleged “multiple remote vulnerabilities” are:
Well maybe it is a problem of validation/sanitization of user-supplied input in the commands: MKD and DELE because when used like so : expl.exe -h hostname -u user -w passwd -p port(21) -o 1 ../../folderName, you can delete folders, or used with -o 2 you can make folders up 2 dirs for this example. The server is acting like it is supposed to just that you can traverse directories using those 2 commands followed by this syntax ../../../../../.
I hope it helps ,all the best
Thankfully, he is at least polite – I’ve done this sort of dance on more than one occasion with discoverers who are not only wrong, but also rude and aggressive with it.
Surely I’ve misunderstood Flo’s point, because it doesn’t sound like “the server is acting like it is supposed to” matches the term “multiple remote vulnerabilities” – so I ask him point-blank:
For this to be an exploit, it would have to demonstrate that you are able to delete a file, or create a directory, in a location to which you have no rights at all [to do that]. Is this what you are saying?
It sounds like you are saying only that “../” is a bad thing to accept, and that I dispute – relative directories are perfectly acceptable, except where they allow you to exceed your rights and avoid a check on permissions.
In response, Flo tells me:
well basicly yea that’s what I meant and I respect your argument.
Let me know if there is something else ,I’m sorry for the confusion.
All the best,
All this, and the tag-line of “Multiple Remote Vulnerabilities (0Day)” spread around the Internet on my server, just because Stefan doesn’t like a server that accepts “..” – I’m sure you’ll understand that this isn’t a behaviour I’m going to change.
“..” is a natural part of paths on Windows and Linux, and it’s a natural part of FTP virtual file systems. The mere act of accepting it is only a directory traversal vulnerability if you can use it to access files and folders to which you should not have access. Neither Flo nor I can find a way to do that outside of the security protection systems in WFTPD and WFTPD Pro.
Does this mean he will retract his claim of a vulnerability? No.
Does this mean that the vulnerability databases will be removing this vulnerability? Apparently not that, either.
So, now someone researching my software finds an “unpatched vulnerability” that never actually existed.