SEEKING WORK - Orlando, FL. United States. Remote.
We are software consultants that focus on application security. Whereas security consultants usually do not have the bandwidth to take on developer roles and many developers usually do not understand application security, we seek to fill the gap.
To the other freelancers who might be reading this:
Please do read our blog. We post a lot of information there with the intention of raising awareness of application security issues. Some of this information might be very helpful. We strive for weekly posts and every blog post is Creative Commons.
So far, one of our blog posts has already influenced an open source security project and we've only been writing them for a month now:
They disabled it server-side? What about the CA certificate in all these Lenovo users' trust stores that blackhats can now use to MITM with wild abandon?
It's difficult to be surprised by this turn of events.
It's in poor taste, in one sense, but overall it's the only appropriate response that a satirist magazine could take in the wake of this tragedy.
Followers of Islam the whole world over will continue to ignore these publications nonviolently, though a few extremists might be further radicalized by this decision.
Meanwhile, David Cameron is trying to outlaw cryptography after these attacks. Surely that deserves more of our attention right now?
> I'd be more worried about opening myself to tor than some theorized attack on ssh ciphers.
Most of the attacks launched on Tor aren't in the "remote takeover of the tor server via memory corruption" category, they have (in recent history) mostly been in the form of:
* Attack firefox.exe in Tor Browser Bundle
* Control a lot of nodes, do something networky to discover the user's actual IP/location
What is the threat you anticipate will result from "opening yourself to Tor"?
There aren't any, currently. These libraries are ripped from an in-house framework which has some tests already, but none for the classes we extracted. We created the tests folder in anticipation of actually writing some.
TL;DR - it does everything PDO does (thanks to class inheritance) but also has some nice short-hand methods for getting jobs done quicker. DRY and KISS.
> It's to make sure the author doesn't get left in the dark just because they miss a mailing list digest line.
I intended to address this with my comment here:
> If he gets burned in the process, that's the price Scott is willing to pay to improve.
If Scott gets left in the dark, he feels that it is his fault for making a coding error in the first place. At this point, he no longer deserves to be enlightened. If the vulnerability discoverer feels like being nice and sharing this information first or simultaneously, wonderful. But if they botch it or maliciously post it everywhere else in the world, then no hard feelings. If public knowledge, eventually the problem will be fixed.
The key motive here is that at no point are third parties bound to regulate their behavior or self-censor. At no point will rudeness and/or publicly disemminating exploit code lead to any sort of criminal liability so long as the targets include Scott, Scott's code, and any systems solely under Scott's control.
Scott carries no legal stick. As a third-party security researcher with no business relationship with Scott, you should be empowered to give Scott as much advance/simultaneous notice as you feel is appropriate. With no requirements.
Let me frame it another way: The very act of publishing a security vulnerability benefits two parties: The publisher/vendor/author of the code that contains the vulnerability, and the public. In the case of Scott's open source software, the interest that matters most is the public interest. The public should be informed so they can decide whether or not they wish to continue to trust the code quality that Scott produces.
So what if Scott's servers get rooted and rm'd? He'll wipe them and write better code next time.
At no point will Scott impose any restriction on what you decide to do with your ideas that were inspired by reading his work. Even if your mind goes to dark places. All he asks is, just don't hurt the public. He's not exactly in a position to waive the right for the general public to press charges if you hack into their systems.
> I'm left with the impression that your primary goal is that I publicize any vulnerability to other people, and the secondary goal is that I tell you.
That is correct. If the world knows, then Scott will also be informed.
> It seems that even if I'm practicing full disclosure, telling the author at the same time I tell the world is a 1st order goal.
That is your choice, you are not obligated to do so with Scott.
If he makes a mistake, he wants hackers to call attention to it. He wants people to see his mistakes and how he responds. Maybe follow his example: to accept mistakes graciously, and immediately issue a patch that adequately addresses them.
If he gets burned in the process, that's the price Scott is willing to pay to improve.
Or maybe he's just cocky and is bluffing everyone because he thinks he's too good of a programmer to make a security-affecting mistake. Only way to find out is to audit his open source code and drop 0days onto Full Disclosure ;)
If you're accessing a system a certain way (i.e. accessing certain parts of an application), then your traffic abruptly stops and a Tor exit node IP picks back up, you're hosed.
We are software consultants that focus on application security. Whereas security consultants usually do not have the bandwidth to take on developer roles and many developers usually do not understand application security, we seek to fill the gap.
https://resonantcore.net/
To the other freelancers who might be reading this:
Please do read our blog. We post a lot of information there with the intention of raising awareness of application security issues. Some of this information might be very helpful. We strive for weekly posts and every blog post is Creative Commons.
So far, one of our blog posts has already influenced an open source security project and we've only been writing them for a month now:
https://resonantcore.net/blog/2015/02/remember-me-safely-sec...
https://github.com/psecio/gatekeeper