Slashdot Mirror
The Cost of Crappy Security In Software Infrastructure
blackbearnh writes "Everyone these days knows that you have to double- and triple-check your code for security vulnerabilities, and make sure your servers are locked down as tight as you can. But why? Because our underlying operating systems, languages, and platforms do such a crappy job of protecting us from ourselves. The inevitable result of clamoring for new features, rather than demanding rock-solid infrastructure, is that the developer community wastes huge amounts of time protecting their applications from exploits that should never be possible in the first place. The next time you hear about a site that gets pwned by a buffer overrun exploit, don't think 'stupid developers!', think 'stupid industry!'"
Tools are dangerous. If I want to cut my hand off with a chainsaw, I can. If I want to leave my PHP script open to XSS, I can.
The next time you hear about a site that gets pwned by a buffer overrun exploit, don't think 'stupid developers!', think 'stupid industry!'"
Yeah, yeah. Hate the game, not the player, and all that. If you code a buffer overrun and you get pwned, it may mean the industry is stupid. But that doesn't mean that you're not stupid too.
Most web app exploits ARE the developers fault!
- They don't check their inputs (length) buffer over flow
- They parse or merge database commands (SQL injection)
- They don't limit abuse (brute force retry attacks)
Yes some of these can be mitigated at other levels, but ALL are common APPLICATION DEVELOPER ISSUES! by measure of deployment to number of exploits I would say the programing languages and OS already do a MUCH better job than the application developers...
EA David Gardner -"... but the consumers have proven that actually what they want is fun."
Computers are inherently instruct-able. That's their power, and that's where all security flaws come form. The underlying problems don't arise out of an industry-wide antipathy. If anything the reality is opposite, the entire industry in quite interested in the fundamentals of security.
The problem lies in the fact that we want to be able to tell computers what to do with a wide assortment of options on each of multiple layers(machine, operating system, high level language, and user application). Every one of those layers necessarily includes things we won't want to do that someone else could want to(i.e. security flaw)
This is like blaming car theft on a general malaise towards car security, when in fact it's a simple matter of cars that don't go wherever the driver wants or only ever accepts one driver is nigh useless.
...because we love hearing not only the clamor for new features, but also:
"Why won't you run on commodity hardware? I can get a system that does everything yours does, plus more [including things others make it do against my will], for half the price!"
"Why is your system so much slower? Every benchmark shows that other systems can do X in a quarter of the time [leaving the other 75% for executing malware]."
"Why does your system make it such a PITA for me to do this simple operation, when all the other systems let me [or any unauthenticated user] do it with a few simple lines of code?"
When you protect developers and users from themselves, when you start making engineering tradeoffs that reduce functionality and tinkering and fiddling ability in exchange for greater security and stability, some people start screaming that you've being evil, paternalistic and unfreedomly and not letting them decide for themselves whether they want to make tragic mistakes.
If you design your tools and infrastructure to prevent those with bad intent, it can also prevent those with good intent from using your system.
There is no magical solution that will solve our security needs. In reality, everything will require tradeoffs which developers have to balance out according to what they are trying to do.
The author can think of himself as an artist all he wants to. Here's a newsflash: other "arts" have to do things responsibly, too.
His whole argument is like an architect blaming the bricks when his/her poorly designed building falls over.
America's biggest threat is not terrorism. It's complacency. For such an arrogant industry, IT "solutions" sure do have a LOT of holes. That's what you get when you demand quantity over quality.
I've got a Farside on my cube wall. The caption is "Fumbling for his recline button, Ted unwittingly instigates a disaster." The picture is a guy sitting in an airplane seat about to grab a switch that's labeled "wings stay on" and "wings fall off".
It's a reminder to me to try to avoid giving my users a way to shoot themselves in the foot.
On the other hand, people need powerful tools to get their jobs done, and those tools can do horrible things when used incorrectly. There's only so much we can do to make things safe.
I .NET there is no buffer overflow or html inject (querystring and post data are scanned by default) or sql inject (using SqlParameter all data are encoded).
I "feel" a lots safer about basic security problem.
The article focuses on security problems that have been largely addressed, in exactly the way he's complaining hasn't happened yet. He focuses on smack stashing and buffer overruns, for example...and disregards the latest higher-level languages that manage memory in ways that makes these attacks far less common. He entirely ignores the most frequent and effective attacks (XSS, SQL injection) nor does he talk about the underlying causes of such vulnerabilities. (I, for one, am extremely curious how a SQL injection attack can be the fault of a fundamentally insecure operating system, since in many cases the attack traverses across multiple different OSes with nary a hiccup.) I'm not entirely convinced that he even understands the current state of what most vulnerabilities look like, to be honest. And finally, he gives absolutely no indications as to how to accomplish this lofty goal of an OS that would prevent there from being such a thing as an insecure app in the first place. It looks to me that all he's doing is whining about the fact that he's having to learn about proper and secure programming methods, which is taking away from his hobby of eating bear claws two at a time.
For your security, this post has been encrypted with ROT-13, twice.
Gimme a fuck'in break!
People aren't clamoring for a new browser update any more than the latest flash player.
This crap is forced down their throats in an effort to grab market share, screw competitors and make a buck.
Customers have almost no direct control.
Forget about protecting me from my bugs ... how about protecting me from the OS's bugs? Windows has so many bugs in very basic functions that I'm amazed anyone manages to write robust software.
For example, the atof() function, which has been around since at least the 80's (probably the 70's) still has bugs on Windows. Microsoft's documentation says: "The function stops reading the input string at the first character that it cannot recognize as part of a number." No, it doesn't. It will keep reading until it hits a '\0' even though the extra bytes it is reading won't impact the returned value. This can make reading a number from a large buffer excruciatingly slow. And, if you aren't lucky enough to have a null byte hanging around at the end of the buffer, atof() might just keep going until it tries to read outside of your program's memory space, causing the OS to kill it.
Building robust software on Windows is like building a house on quicksand.
WTF, seriously? You're going to post this to a tech site?
What fucking moron decided to write this summary for slashdot? What fucking moron decided it was a good submission? Yes, I realize the answers are blackbearnh and Soulskill - seriously guys. It's shit like this that makes me wish I read CNN instead. Stop insulting your readers.
Go ahead and mark this post flamebait - that's what the article itself is, so I am just posting in kind.
Yes, because way back in the olden times, before the clamoring for new features overtook infrastructure stability demands, things were completely secured. Never mind that many of the infrastructure components from that era still in use today have to be protected by layers of modern security due to the huge and gaping security holes... we don't have time for actual facts!
software community has a massive blind spot, and this is the inability to identify root cause. think not? identify one process once a developer checks in code that identifies and resolves root cause. our industry every day spends millions of dollars automating bad process. only we can fix that, and there is no better place to do this, than in open source, because there are no constraints. it will not happen in industry, this is where open source efforts can truly lead the way.
Blaming the users, developers, tool chains, internet, or operating systems isn't going to help fix anything because those aren't the root cause of the problem.
Complexity is the problem. The solutions we're all used to using involve adding even more complexity on top of things, which makes it impossible to secure things.
There is another approach. It's called capability based security, and here's how it works:
For a given process, create a list of the files it needs to access, and the rights it needs for each. That list goes to the operating system, along with the program to run. The OS then checks the list consistently any time a file or other resource is needed. There is a special (but not onerous) way for the process to request access for other files from the OS (like when you need to open or save a file with a new name) called a "power box".
At no time is a process allowed to just try things out and scan around.
This means that you can simply and effectively limit the side effects of a given program, and not have to worry about buffer overflows, etc... because they can only result in processes which end up with the same limited access.
A capability based security system provides a realistic, reasonable, and fairly easily understood way of providing security which does NOT require trusting code (outside that of the actual OS).
This is the way forward out of the security morass we find ourselves in. I've been preaching this message for a while, and I hope that there are some out there in this wilderness who agree with me.
The article is stupid. But the language and OS problem is real.
First, we ought to have secure operating system kernels by now. Several were developed and passed the higher NSA certifications in the 1980s and 1990s. Kernels don't need to be that big. QNX has a tiny microkernel (about 70KB) and can run a reasonable desktop or server environment. (The marketing and politics of QNX have been totally botched, but that's a different problem.) Microkernels have a bad rep because CMU's Mach sucked so badly, but that was because they tried to turn BSD into a microkernel.
If we used microkernels and message passing more, we'd have less trouble with security problems. The way to build secure systems is to have small secure parts which are rigorously verified, and large untrusted parts which can't get at security-critical objects. This has been known for decades. Instead, we have bloated kernels for both Linux and Windows, and bloated browsers on top of them.
On the language front, down at the bottom, there's usually C. Which sucks. The fundamental problems with C are 1) "array = pointer", and 2) tracking "who owns what". I've discussed this before. C++ doesn't help; it just tries to wallpaper over the mess at the C level with what are essentially macros.
This is almost fixable for C. I've written about this, but I don't want to spend my life on language politics. The key idea is to be able to talk about the size of an array within the language. The definition of "read" should look like int read(int fd, &char[n] buf; size_t n); instead of the current C form int read(int fd, char* buf, size_t n); The problem with the second form, which the standard UNIX/Linux "read" call, is that you're lying to the language. You're not passing a pointer to a char. You're passing an array of known size. But C won't let you say that. This is the cause of most buffer overflows.
(It's not even necessary to change the machine code for calling sequences to do this. I'm not proposing array descriptors, just syntax so that you can talk about array size to the compiler, which can then do checking if desired. The real trick here is to be able to translate old-style C into "safe C" automatically, which might be possible.)
As for "who owns what", that's a language problem too. The usual solution is garbage collection, but down at the bottom, garbage collection may not be an option. Another approach is permissions for references. A basic set of permissions is "read", "write", "keep", and "delete". Assume that everything has "read" for now. "write" corresponds to the lack of "const". "delete" on a function parameter means the function called has the right to delete the object. That's seldom needed, and if it's not present, the caller can be sure the object will still be around when the function returns. "Keep" is more subtle. "Keep" means that the callee is allowed to keep a reference to a passed object after returning. The object now has multiple owners, and "who owns what" issues come up. If you're using reference counts, only "keep" objects need them. Objects passed without "keep" don't need reference count updates.
Do those few things, and most low-level crashes go away.
I won't live to see it.
This chainsaw is too dangerous!
How am I supposed to chop down the tree with a nail file?
There are established and well-founded rules regarding static load and fire protection safety in regulations/laws for buildings.
The equivalent thing would be outlawing the use of C++ for anything carrying confidential/secret information. But what's reality ? Powerpoint is one of the most-used tools along with Acrobat Reader, especially in government, military and big business. So the Risk Of Being Fucked By China is being discounted against Cute Dancing Bunnies.
Some programmers know about the risks, but the typical, experienced C++ guy has his preconceived notions about the superiority of C++ versus anything. In truth, he/she is protecting his/her long-time investment into learning C++. No rationality, no responsible behaviour whatsoever. Most programmers and of course their managers are simply Software Development Whores.
..that's what you are. Just because all the "important" (ie. mostly "rich") keep drumming C,C++, Java, .net and the Microsoft/Adobe Virus APIs means nothing. Just because Mr Bill Programmer-Salesman talks of "Secure Development Lifecycle" means exactly nothing. Just because every C++ coder and their dog think that their particular code is "safe" means shit.
Reality is - C++ is an el-cheapo solution millions of people are knowledgeable in.
Reality is - Microsoft and Adobe are first and foremost concerned about MONEY. Security is not generating money, it costs money - so it's a nuisance to the typical software company. At least in the short run.
Reality is, even the best C++ developers make lots of security-relevant (ie exploitable) errors, because it is so easy. Just check all the bugs in Chrome.
Ask any MBA or beancounter. THey will gladly tell you that IT is a cost center that adds no value so there is no costs at all associated running IE 6 with no security updates after June 7th 2009, on a Tuesday that wont work with intraCrap from MegaCorp.
It is not like any financially sensitive information is ever used on computers anyway and since it is a dollar sink there is nothing wrong with using that and switching to typewritters since after all they are just a cost. ... (... end sarcasm)
My rant above is a serious issue. Especially for hospitals for HIPA requirements that still use IE 6 and unsupported who no updates, XP SP 2. The bean counters tell doctors what medical appropriate procedures to run too and not just how to handle IT and it drives me crazy when I contract work for them.
The worst offenders are not that McCrappy or Symantic endpoint, but software that is 100 security updates behind! Can't get more updates because the intranet app developers are lazy and do not want to support it, or are evil and do this on purpose so your employer can buy version B for $150,000 so they can run updates again or join the rest of the world and join Windows 7.
A patched Windows 7 office with IE 9, up to date updates and no flash or outdated java running in the internet zone, is like 300% more secure. The calls for malware go down drastically. The problem is always the MBAs and the obsession over the share price going up.
http://saveie6.com/
I am sure the Chinese Air Force likes those RSA "security" tokens, which gave them the one-time passwords to Lockheed-Martin networks and lots of juicy F-22 data.
Boy, throw away all commercial security thingies and learn how to roll your own (e.g. use a J2ME app to perform two-factor authentication). Then you know the real risks and can keep the Chicoms out. If not, you are just a Victim.
"Why can't your system display Dancing Bunnies from IdiotTube ??"
How is crappy s/w different from the local police?
No news here I say.
Sorry for being condescending, but all you describe is already out there. AppArmor, for example.
The problem with your post is that you view it as a Silver Bullet, which it is not. I agree that it would seriously improve security and should definitely be done. I agree that managers are fucking idiots if they don't allocate time for creating sandboxing profiles ( typically requires just a few days of engineering time),
But at least "simple" sandboxing is not a Silver Bullet for several reasons. Imagine you are the security admin at Lockheed Martin and you duly create all these sandbox profiles. So you create a profile for this dangerous piece of crap called "Powerpoint" (e.g. using "Sandboxie"). From now on Powerpoint processes on Lockmart computers will only open *.ppt and *.pptx files. Nice. But now comes the Chinese Spearfish and extracts 1500 Powerpoints to Chengdu from Mr LockheedMartin CEO. These files contain all the summaries of the hard work of Lockheed Martin Scientists and Engineers, including key measurement data.
So the Chicoms could not download the "raw" measurement files (say radar signatures from differen aspects to 0,1 degree accuracy), but they got all the highly secret "tips and tricks" related to controlling the signature, the type of absorbing paint used, the maintenance and operations issues. That is how powerpoint is used in a modern big business - it is used to store and communicate critical data and "know how". It contains the essence of hundreds of man-years of engineering work and that is exactly what intelligence is about - extracting knowledge, not extracting low-level data.
So boy, go back to your "thinking zone" and come up with something vastly more complex and nuanced. And then, please integrate it with existing business workflows, consider the ergonomics of all that. Sandboxing is valuable, but it is by no means a Silver Bullet !
We can have a wide open no holds barred space to create anything good, bad or indifferent. Or we can lock it all down according to someone's idea of safe, fair and convenient. Under the second plan. a thousand things you are going to want to do will not be possible because they exceed the mandate of the security environment (no matter where you arbitrarily draw the line.) So you get to pick your demons. Me I like it the way it is. That's just me.
..was done in a PASCAL variant. They had lots of users who loved the stability and ease of use. Unfortunately, Unix and WNT came along, so the corporate drones killed it. Sad.
http://en.wikipedia.org/wiki/HP_Multi-Programming_Executive
See here:
https://sourceforge.net/p/sappeurcompiler/code-0/2/tree/trunk/doc/manual.pdf
This is a compiler I implemented two years ago. It is still quite rough at the edges, but I do think it could already be useful for some real projects.
Unfortunately, the reception on the interwebs was not really positive. Programmers are fiercely loyal to whatever they know best; similar to catholic popes and religion. Most programmers are actually completely closed to rational discussion about programming tools. So maybe, yes, you won't live to see real-world, high-performance programs in a fully type safe language in your lifetime.
You might as well blame the users while you're at it, since it's a rare client indeed who buys a system with security as their #1 priority. In fact you're lucky if security is anywhere in the top 5 choice criteria, and that's for enterprise buyers. In the retail world it's much, much worse than that.
I've seen the RFP's. IT gets their share of criteria, and it accounts for maybe 15% of the total score. Security has to fight it out for a small portion of that 15%. It sucks but ultimately money talks and the developers/vendors/authors respond to that. Even in the FOSS world, where money isn't such a driving factor, if the audience isn't selecting software based on security, how much effort can we really expect the programmers to put into that part of the system?
The high-level ideas of Java are sound, but the implementation (or "execution" in manager-speak) has been, and still is, awful. So awful that it is now considered a security risk to have Java Web Start enabled in browsers. I also managed to crash a JVM (about a year ago) by running a PDF parser on the JVM. I am quite confident a properly crafted PDF could have taken over my user id. So, in practice, Java is highly dangerous.
A properly failing program is vastly more secure than one which will open the gates to the confidential database. A proper exception stacktrace can usually be used to fix programming errors. Your post is actually demonstrating your security saviness. Proper programs do not "catch exceptions by random code". Unexpected exceptions should terminate the thread or maybe the whole process, depending on the circumstances. And that is the default behaviour.
That's vastly more secure than CAD workstations.
In my case, the cost of crappy security is $107,000. Thanks to our mission-critical software having CWE-732 and CWE-602 we have to move everything away from the workstation clients on to servers to secure them. All these damn users on 2003 (Because the software doesn't work on 2008/Vista/7) Terminal Servers is costing us a fortune.
for a home machine why not run a GUI?. It's not like it hurts anything.
It is not about freedom, but about the egregious laziness, ignorance and anti-professionalism on the side of the "management talent". These people are happy so spend fortunes on lawyers and to listen for hours to lawyers, but they think it professionals should better be ignored.
Interestingly, the language that does this best, is also the second worst language ever invented (after PHP). In ColdFusion, if you do this:
select * from cats where cat_name = '#catname#'
Oh, wow. That's like PHP's mysql_real_escape_foo() and it's so wrong it hurts!
Because to know how to "quote" something in SQL you need to know the context (e.g. am I assigning/comparing to an integer column? Am I using the quoted snippet as a name?) -- and you aren't thinking the PHP libraries (or the Cold Fusion ones) are parsing the SQL statement to find out, are you?
But then, PHP has PDO, which kind of works. People still sell mysql_real_escape_blahblah() as the panacea.
It's our own stupidity, my friend.
how would a capabilities-based system help in my scenario of these 1500 pptx files ?
"Everyone these days knows that you have to double- and triple-check your code for security vulnerabilities, and make sure your servers are locked down as tight as you can. But why? Because our underlying operating systems, languages, and platforms do such a crappy job of protecting us from ourselves".
That's not true, if the underlying Operating System is designed with build-in security, then any potential security vulnerabilities in the applications are very much mitagated and baring software bugs, the Linux security model does the job.
AccountKiller
"avoid buffer overruns you have to do bounds-checks at run-time. But these are very expensive." In the real world, this creates a runtime overhead of about 10 to 20%. Hardly an issue compared to the security costs of a successful penetration
...is that every C++ programmer thinks he is writing "robust" code and that array bounds, safe pointers and so on are not necessary in their case. Because they are so special, of course. Reality is, people make mistakes in anything non-trivial and the bad guys will exploit these mistakes. And that includes things like the Linux kernel and Google Chrome. I don't know the situation with ::std::string, but ::std::vector::operator[]() does not check bounds and it is used millions of times in real-world code. So the STL promotes unsafe-by-default programming.
Finally, C and C++ do have no proper concept of multi-threading and there are probably millions of race-condition problems waiting out there to be exploited by the Russkies and Chinese.
What if OS developers used the same logic: "Why should we build a secure OS if every app that runs on it is going to have blatant security holes in it?".
The answer is that you aren't trying to make your systems impenetrable, what you are doing is trying to design it so that *WHEN* it is penetrated it won't be your fault.
but have you ever seen a manager sitting down with his most experienced software developers and system admins and tell them "let's design a security policy which is both effective and acceptable to end-users" ? Surely they shell out lots of money on IT, but all the reasoning related to security risks boil down to "we are a business and we these twenty-five plugins installed on all corporate PCs". Convenience trumps security any time, in my experience. Security is definitely not managed - it is considered a nuisance and something not really worth bothering about. A "chief security officer" will be appointed and then the subject will be ignored, when the rational thing to do would be more user education and designing security policies and processes in a way that integrate into the business processes. As opposed to obstructing them and then being circumvented by users. The underlying reason for that sad reality is a lack of management attention and serious desire to improve that aspect of the business.
Yes: "Well designed equipment today is much safer ... reality that industrial accidents are everyone's problem. The resulting disabilities are a tax on society."
Yes. "The argument that safety is futile and no effort should be made to improve it is the voice of laziness"
No: "A remote code execution exploit is a serious matter and should be accounted for in business decisions while calculating risk avoidance. "
How the heck can you calculate the financial loss from malware inside your network ? It might range from the mundane to the destruction of the company, if a capable, cheaper-cost-base competitor gets the complete crown jewels.
Also, you are regurgitating the Beancounter/MBA Fallacy "what you cannot quantify you cannot understand and change". We all go great lengths in terms of hygiene and use of condoms, without anybody calculating the "financial loss" from AIDS or the plague. We know it is horrible and we spend serious effort (e.g. daily dishwashing) to make sure we don't get the diseases. Also, I find it completely impossible to quantify the losses from an exploitable weakness. There are too many variables inside and outside your company to make a proper statement.
All we can say is "damage might be from zero to complete financial destruction of company". Of course, you might make a more detailed statement if the exploit only matters in a specific department (e.g. only accounting uses Windows and the exploit). But still, how can you properly quantify your financial details being in the hands of your asian competitor ??
Yes: "Well designed equipment today is much safer ... reality that industrial accidents are everyone's problem. The resulting disabilities are a tax on society."
Yes. "The argument that safety is futile and no effort should be made to improve it is the voice of laziness"
No: "A remote code execution exploit is a serious matter and should be accounted for in business decisions while calculating risk avoidance. "
How the heck can you calculate the financial loss from malware inside your network ? It might range from the mundane to the destruction of the company, if a capable, cheaper-cost-base competitor gets the complete crown jewels.
Also, you are regurgitating the Beancounter/MBA Fallacy "what you cannot quantify you cannot understand and change". We all go great lengths in terms of hygiene and use of condoms, without anybody calculating the "financial loss" from AIDS or the plague. We know it is horrible and we spend serious effort (e.g. daily dishwashing) to make sure we don't get the diseases.
A mainframe guy I was having a internet conversation with claimed that S/360/390 (whatever stupid name they currently use) operating systems normally don't expose this C/C++ weakness of passing around pointers to buffers. They always have the length field with the buffer, so that all routines can be securely implemented. Only with Unix and WNT came these stupid things like sprintf().
So your "irony" might actually be close to the truth. Just don't confuse Unix with "old". Old is the mainframe stuff and I never heard of Virus scanners for these.
...that this would really work properly. Because that would essentially erect an impervious border between the user-generated pptx files and the "pptx from email" files. User might want to copy a diagram or some text from "pptx from email" file into their own pptx files. They would want to store these pptx files in some local repository (such as sharepoint or SVN).
But yes, your approach would definitely shore up security dramatically.
Maybe a "secure rendering" and a "secure clipboard" function of the operating system could facilitate that. These facilities would accept only very simple formats (such as ASCII text or bitmap files) from the Powerpoint process which has an "pptx from email" currently opened. It would definitely kill the cut-and-pasting of nicely formatted and colored tables, but that would be IMO an acceptable price of good security. .
The "store outside email system" issue could be fixed by tagging files, similar to the way secret information is labelled in government. A file labelled "external" would always run inside Powerpoint in the restricted fashion as described above. Only files labelled "internal-project-x" would allow for copy-pasting of files which are also labelled "internal-project-x". Copy-paste to "internal-project-y" would not work. .
In the end, what matter is real workflows and how to secure them without forcing the user to do stupid and/or very time-consuming things. Simpleton solutions won't cut it, as they are almost always too restrictive.
Finally I think it is very, very, very important that the security system will tell the user why some operation is not permitted. Additionally, users have to be well-trained in all aspects of that system, or they will simply hate it and try to circumvent.
..how would you protect that CTO of a technology company ? This man needs access to 1500 pptx files to do his daily work, he needs to communicate by email. A single spearfish email could take over his powerpoint process and then do all kinds of reconnaissance/extraction/collection on these 1500 pptx files. Don't tell me this CTO does not need external email. That is too restrictive, as this man needs to communicate with external customers and partners. I am genuinely curious.
All of your ideas will not defend against malware extracting your secret data to google mail or displaying bogus data to you. You would still enter your facebook password via a web form under the control of malware.
Experts say Macs will be targeted more and more in upcoming years. Low market share is no longer protecting the platform, it seems.
It would probably be unnecessarily clunky to ask the user before App X can access a file. Better make it like Google Chrome: The "file open" functionality is part of the operating system sandbox. When you open file fa, it will start a process PA, configure it to just have access to fa (and the file it always needs to properly function) and command it to open fa. That way a spearfish file fs cannot access any other files.
This approach will not work for indexing engines and probably not for IDEs,though.