Slashdot Mirror
Hackers Find Use for Google Code Search
An anonymous reader wrote in to say that "Google has inadvertently given online attackers a new tool. The company's new source-code search engine, unveiled Thursday as a tool to help simplify life for developers, can also be misused to search for software bugs, password information and even proprietary code that shouldn't have been posted to the Internet, security experts said Friday.
"
Isn't the point of open source that anyone can fix the programs? If it can be used by attackers it can also be used by developers. This is a pretty pointless article anyway as it's not that easy to find security holes in programs - if it was that easy then the developers would have patched up the holes already.
Slashdot readers beat 'em to it!
The previous story /. precipitated comments that did exactly that.
only to those whose "security" in reality consists of not much - or even nothing - more than obscurity.
:%s/Open Source/Free Software/g
YTARY!
How is searching for something misuse of the search engine? I'd say that the Internet was misused by those who made the information public in the first place.
If you accidentally put something publicly available on a web page, it can be found, manually or by a search engine. This is really no different from how it has always been with text, images and anything else that you can put on the web.
Swedish plasma phys. PhD student; MSc EE; knows maths, programming, electronics; finance interest; seeks opportunities
"Powered by phpBB" in order to find phpBB boards that were vulnerable to an exploit to hack. This isn't exactly a new technique. Well ok I know it's not exactly the same thing but the idea is still the same.
I think previous posters got it wrong. They say the cracker access to the code is just as easy as anyone else's who can fix it. But a developer looks only for the code he's involved to, while the cracker is looking for any exploitable program. That, and although coders eventually search for security holes, he's goal is to build features. So, it indeed is making it easier for the crackers.
Which is a good thing, if you realize bad environment also leads to evolution. More bugs exposed, the more developers will fix them, and maybe one day software designers will get it right, stop using insecure programming language, and write safer code.
factor 966971: 966971
People need to stop blaming those that provide tools and research for their finding or their ability to find bugs and errors. It's not their fault. If you screw up and someone finds it, it's not their fault, it's yours. Take responsibility and deal with the consequences.
The people that make the problems usually cry that the entire world needs to tell them about their mistakes in a nice quiet, private way, so they can silently fix them and avoid any unnecessary damage. The reality of this, as we have seen time and time again, is that when they are informed of these problems, so often they go ignored for months and months. And then the issue is finally leaked and they cry you didn't give us enough time! No, it was your fault to begin with, it doesn't matter if someone else made your mistake worse, none of this would have hapened without you screwing it up to begin with. This is how the world encourages you to try harder to get it right the first time instead of tossing us crap and fixing it later.
In summary, anyone that fights against auditing tools clearly has a quality control or security issue they are unwilling to fix and are afraid to have exposed.
(The whole model of "sell crap, fix later" is broken from the get-go. That's why we have crappy software hustled to the store in "version 1.0.0" form and have to beg the authors for bug fixes for the next half year. Problem is they already have your money, and that upgrade is free, so why should they pour resources into a 1.1 when there's no more money to be made? It's a losing proposition if you don't intend to release a paid 2.0 later, or if you think you can sucker them a second time)
I work for the Department of Redundancy Department.
Today's "hacks" mostly go for widely spread software. Why? Simple. For maximum impact. There are, of course, still targetted attacks, but those targets tend to be machines and nets of high interest for the hackers. If you use insecure software there, you earned that hack well.
So the key target is to get access to as many machines as possible, to create spambots, to phish for information, in other words, the key target for attacks is the machine of the common man.
Now, which approach would be more fruitful? To find a neat exploit, find out which software contains it and then match it against the software usually used by Joe Average? Or to do it reverse, find out what Joe uses and find exploits in that software?
I think the recent revelation of buffer overflows in MS-Office and the Javascript exploit in the IE answers that question.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Linux is *not* user friendly, and until it is linux will stay with >1% marketshare.
So if Linux gets user friendly, it will drop to a 1% market share? Sounds like a reason to keep it not being user friendly!
I can't read code - it means absolutely nothing to me. So this whole point on OSS being transparent and knowing what the software really does, doesn't apply to me. Hell, if someone were to show me the source code to both Windows and Linux, I probably wouldn't even be able to tell which OS was which. All I care about is whether the software does what I need it to do; I don't plan on spending any evenings curled up to the fire reading source code.
So this leads us to the next pro-OSS argument, that if the program doesn't do what you want you can either make a solution or hire someone to do it for you. I've tried this (several times in fact), and it didn't work. Since I don't program I have to go out and hire someone to code the solution I want. Never mind that finding a coder can often be a royal pain, but each and every time not only has (or would have) it been more expensive to hire someone to code the solution, but it took longer than had I gone out and bought a commercial closed source package (or two) that did do what I want.
Lastly, I keep hearing how OSS programs are more nimble and should a bug or needed feature be identified, 'the community' will solve the problem much faster than a closed source solution. That may be for popular projects like Linux or Firefox, but in my experience I find the OSS programs to be less responsive to requests and needs than the closed source solutions.
As a scientist, I'm all for transparency and free flowing information. However, when push comes to shove, I need programs that work, and, while I really hate to say this, the OSS programs have always fallen short.
I ran into a situation at work recently where we (note, we're statisticians, not programmers) discovered firsthand the value of having the source code to a piece of software. A proprietary program we purchased was calculating a value incorrectly because it wasn't taking a certain factor into account that most people don't need, and there was no way to get it to do that. My boss' comment: "And we can't fix it because we don't have the code."
Her point was right on target - if we had the code, we could've easily contracted out fixing the program; it probably would've taken a competent programmer a couple hours to put the fix in and test it. But instead, we're stuck with a software package that's useless for many of the situations we wanted it for, unless the developer decides we're important enough to fix the software.
When this happened, I realized that the general public is becoming much more aware of the potential problems with closed-source software. For now it might just matter mostly to programmers, but sooner or later, it'll matter to a lot more people, too.
Her point was right on target - if we had the code, we could've easily contracted out fixing the program; it probably would've taken a competent programmer a couple hours to put the fix in and test it. But instead, we're stuck with a software package that's useless for many of the situations we wanted it for, unless the developer decides we're important enough to fix the software.
Just out of curiosity -- HAVE you contacted the developer asking for a fix? Just because its a closed-source solution you can't fix yourself, doesn't mean the vendor won't fix it if someone asks. Especially if its really as simple as a couple of hours (although there is always extra overhead, such as back-testing, etc.)
Disclaimer: I work for a closed-source software vendor, but we try very hard to meet the needs of all of our customers, so if they identify a critical issue we generally try to either find an acceptable work-around, or patch the code when possible. And (ideally) that would be done in such a way that you won't lose that fix when you upgrade. If you custom-fix your OSS solution, you either have to never upgrade, or patch every version that comes out; that seems to be a lot of long-term hassle.
Customer satisfaction is a big part of being a software vendor -- sure, you may be a small customer, but if my company is responsive to your needs then that builds good relations with you, and you may be an excellent referral source for us later (or become a larger customer yourself). That's a strong motivation for businesses that really care about their customers. And for professional-type products, buyers are more likely to pay extra for that good service.