Slashdot Mirror
The Fine Line Between Security and Usability
SkiifGeek writes to ask, "Where should vendors be required to draw the line when supporting deprecated file formats and technology? In a recent case independent security researcher cocoruder found a critical bug with the JET engine, via the .mdb (Access) file format, he reported it to Microsoft, but Microsoft's response came as a surprise to him — it appears that Microsoft is not inclined to fix a critical arbitrary code execution vulnerability with a data technology that is at the heart of a large number of essential business and hobby applications."
Microsoft is a company, there goal is profit. Not security, not saving the enviroment, not making linux geeks smile. They want money. As every company on earth does. That is where the line is drawn. Exactly where it becomes unprofitable.
So basically, -1 troll/offtopic is really slashdots way of saying "I hate that you thought of something before me."
Mordac, the preventer of information services, makes a statement on security versus usability:
http://dilbert.com/comics/dilbert/archive/dilbert-20071116.html
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
... that Microsoft doesn't want to fix Jet.
.NET in it.
They'd rather you re-wrote your app and used MSDE, or something with
Not a lot of money in supporting the db engine they give away.
And this is not the first time. Does no one remember they tried to Kill Jet in XP -and- Vista?
A pox on them all. I hope we re-write our app in mySQL.
deleting the extra space after periods so i can stay relevant, yeah.
a few years back, I started up a software company. Although some of our stuff was open source, starving isn't a hobby, so some of it was closed. One thing we tried was (for a slight increase in price) guaranteeing to fix any critical bugs even if we no longer supported the software. If we couldn't provide a fix, the source code was in escrow so they could access it. There was zero interest in it.
Do you even lift?
These aren't the 'roids you're looking for.
It's a very old technology. No new projects start with Access in its heart.
Umm, isn't that the format used in the most popular voting machines to store all our votes?
IMO this potential exploit is useless unless you're doing something with a JET database that you shouldn't be anyways. JET doesn't have database transactions, sure if you want to you can write them in at the application level but that's incredibly costly. If you're allowing people you don't trust to access a JET database something is wrong. JET will screw up if two users try to modify it at the same time, so why would someone you don't trust be using it, they could just as easily cost you enough damage by just modifying the DB while you are. SQL is used for that sort of thing, NOT JET.
If i had one dollar for every brain you dont have, i would have $1.
So to fire off this vulnerability, you have to run an .mdb file you found from "somewhere." Never mind these things could have embedded VB macros and other controls that could wreak havoc.
Why not just start running installs you find from "somewhere?"
Access and mdb are insecure as it is when you start running untrusted files; should we expect all of those to go away at the expence of neutering the key selling point: stupid easy to do anything with?
Sounds absolutely great. I wish every business person was as smart, since open source is obviously better in every way than closed source.
End of sarcasm. Yeah, open source is pretty cool, I like it, etc. Does open source guarantee everything wonderful, does open source guarantee a business with a profit? No, it doesn't. Open source is not the answer to everything.
And even open source organizations will stop support for decrepit applications. If you insist on using a 10 year old Linux kernel and demanding that some quirky bug in it be fixed, I'm not sure how much support you'd get :)
Is that an exact analogy, no... but, as a previous poster said, businesses run on profit, not open source feel-good-ness... :)
No; I know of no industry that works like that other than software. First, if a product is defective, I can return it and get it refunded or replaced. Beyond the warranty period, I still have the ability to alter it myself. Not so with software -- I can't return an opened package, even if the program doesn't work, and the EULA prevents me from making ANY modifications. Also, 10 years from now if it is discovered that my model of car has a "security risk", i.e. it explodes at random without warning, the manufacturer can still be held responsible. In this case, the software companies are trying to ditch any responsibility for their product, and require that the user pay them again for a newer version if they want their problem fixed. What's really stupid is your suggestion that the consumer is obligated to deal with a defective product.
> why do people keep using access? It is so dinky as a relational database... I'm not honestly sure what it *is* supposed to be used for.
:)
Microsoft Access is a demo. It's meant to seduce you into thinking that developing your own database applications is easy and fun, and that Access can address your organizational needs adequately. This puts you onto the path that will eventually lead to you buying MS SQL Server.
At least, that's been my experience!
"Slow down, Cowboy! It has been 3 years, 7 months and 26 days since you last successfully posted a comment."
Unfortunately, with Access, it's not about the database itself, but about the GUI tools that many people find easy to use...
Xfce: Lighter than some, heavier than others. Just right.
They're making a big deal of the following in both of the links in the article, repeating the same phrase over and over: "some web servers could be at risk if users upload a malicious .asp / .mdb file and then execute it via calls to "ADODB.Connection"."
They say this twice in one paragraph at one point.
But what does that really mean?
That means a server running ASP, that also is allowing end users to upload .mdb databases to it (???), AND to expose them from whatever location they've been uploaded to so that Connections can be made to them, will be vulnerable.
That's a pretty hefty list of "ifs". If you're letting your users upload .mdb databases to your webserver at all, let alone to a publicly accessible folder, you're already asking for severe trouble. I can't imagine a website out there that would allow such uploading/public exposure to happen that doesn't already have severe security flaws merely by the amount of freedom its given its users in what they can do on the site.
This is definitely a vulnerability, but the impact to ASP/ASP.NET servers is minimal if the hosts are implementing common sense security practices/user restrictions already.
-Vendal Thornheart
"Access is the path to the dark side, for Access leads to SQL Server, and SQL Server leads to suffering."
Well, that actually is my problem with FileMaker Pro. It too seduces you into thinking that developing database apps are easy and fun. The difference is that when an FM Pro app starts flaking out (public school systems are just eaten up with FM Pro deployments that got too big for their britches) there isn't a "big brother" product to easily transition to that scales.
Yeah it's true that Access is a gateway drug to SQL Server. But that IS a viable upgrade path for that little workgroup app that some PHP decided to expose to a 10,000 node WAN.
No matter what is written above, it's not just "Small business" which use Jet. I'm under an NDA(s), so won't name names, but lets say that, in the course of the last 18 months, I have worked in 1x Top 5 Bank and 2x top 10 financial services houses, in the UK, that would collapse if they loose their Access Databases within one week. ( Guess what my firm was brought in to do?) It's a similar situation to the household name that most people in the UK and US have some direct or indirect monies held in that currently has more than 700 staff in my company working 24 hours a day, 7 days a week to get all their data into a new data ware house after a rather worrying period where their main DB went down. What was the DB? It was a massively hacked about version of a CRM package that a developer got off a coverdisc ( PCPro magazine to be exact ), 6 years ago. Here's the thing: Big companies get into the same messes as small companies. If you truely believe that ALL of the top companies are using Oracle DB's, SOA architectures and data warehouses for mining purposes, your living in a dream world. Working as a solution architect that is meeting 2-3 major, as in top 250, clients a month, and looking at their issues, and the mess that they've got in to, I would be suprised if Microsoft manage to hold their "We're not going to fix it" position for long. Fact is, as soon as CIO's get stressed, they start to shout, and they'll shout at Microsoft if they feel that there is an issue. Remember that a lot of the major firms have 10 and 15 year support contracts with Microsoft, each of them bespoke. If one of them demands a fix, it will immediately be made available to all of the others on bespoke support contracts. At which point there is little reason to hold it back from the other major buyers, and so it cascades down the chain.
OpenBSD is also one of the most useable UNIX systems I've encountered. It doesn't have oversimplified GUIs, but it does have a remarkably consistent userland feel. Why? Because the team regard usability as part of security. A security system that is so hard to use that people turn it off is a useless security system. The best security system is a competent administrator and a good user interface lowers the bar for competence.
I am TheRaven on Soylent News
Access is not a database, it's a RAD tool for data-drive apps. You use Access when you want to quickly create a GUI for processing data (well, now you'd probably write a web app, but in the '90s it was the thing to use). Once you've done this, you progressively add features to your simple tool. Eventually, you have something that sprawls over thousands of lines of unmaintainable code, depends on Access, and is vital to your company.
I am TheRaven on Soylent News
The cost of maintaining Free Software follows a curve. You can fairly easily predict how expensive it will be to keep maintaining something you depend on, and how expensive it is to move away. Once it becomes cheaper to move, that's what you should do.
I am TheRaven on Soylent News
I thought it was just a way of keeping a bunch of copies of the same spreadsheet in one file. Not sure why they call them tables instead of spreadsheets though :)
Visual IRC: Fast. Powerful. Free.
Security
---------------------
Microsoft
Was that so hard?
I've scaled FMP out quite nicely, actually. I think the problem you're more likely running into is one where poor database design and implementation does not scale, regardless of the engine used. Since you mentioned school systems, here's some examples of particular design and implementation mistakes I've run into in that environment.
- Keeping all student records in one table, in perpetuity, so the engine has to slog through records from 10 years ago to find today's current students.
- Keeping all records, for all tasks, on one DB machine, in one set of tables, rather than using separate machines (why should the student attendance records *always* be on the same machine as the cafeteria menu, the janitorial schedule, the PTA newsletter, and the 2001 teacher vacation sign-up sheet?)
- The BigTable. Everybody who's worked in cleaning up poor DB design knows this one, the freaking huge table that stores *everything*. As text fields, of course. With no relational links.
These simple design gotchas can be made with *any* db engine, and are often made by inexperienced designers. Easy and fun is setting up the basics, and when it gets slow, paying some geek (or finding a young volunteer who needs to pad their resume) to re-engineer the system.Of course, there are an awful lot of inexperienced db admins out there, who have only worked with scaling one or two kinds of db engines, and thus lack the history of "scaling" back when 30Hz and 64Mb of RAM was the maximum per desktop (and thus lack the tao of partitioning zen), or are used to using their "clustering tools" (and thus lack the tao of systems connections zen), or any other number of failings which prevent them from understanding how to actually scale something really big.
If you're applying for a job as a DBA (or are the chief teacher/DBA for a school system), and you don't understand how DNS scales, well.... there ya go.
MS Exchange doesnt use Access, and it doesnt use the same 'Jet' as what Access defaults to.
Exchange uses a database technology known as ESE that was at a time known internally as 'Jet Blue'. Although its got the word Jet in it, it is not the same as the 'Jet' engine that Access uses.
Read more at Wikipedia. Particular note the difference between ESE and Jet Red.
Of course modifying an mdb file causes a vulnerability. It would be stupid for it not to. As an analogy...he's saying that he can modify an executable file to execute arbitrary code. Well, duh! Since an mdb file can already have executable code in it, in the form of macros, references to ActiveX controls, and vba code, to treat it as anything but an executable is stupid. Microsoft Outlook and other email programs already treat mdb files as suspect. There are plenty of legitimate security holes around, but this isn't one of them.
I think the comments here regarding access as being tinker toy software are off the mark. Access has enabled scores of people to solve problems and manage data themselves.
.NET code? Or would you rather they ask IT to develop and application to do these trivial things?
Sure, you can sit in your geek tower and laugh at the dolts that use Access every day to solve thousands of data management issues. A secretary can be trained to use Access to manage moderately complex data (the numbers on all the new telephones, people interviewed for specific positions and letters sent relative to those positions, products bid out and vendor responses and on and on and on).
Do you really propose that she/he write a web application for this? Or just hack up some Perl with mySQL to manage these things? Or whip out a bit of
Access has solved real world problems for real people for a long long time and will continue to do so regardless of how data and/or system design snobs feel about it. It is an empowering piece of software. I think some of the attitudes here are IT centric and not in keeping with the real business end of most companies.
There, fixed that for ya....
A house divided against itself cannot stand.
Access *has* solved real-world problems.
It has also caused real-world problems.
I have seen *way* more improperly-coded applications in Access and Excel than in any other language or programming system. Why is that? Because people are designing "databases" with no fundamental understanding of data management. People code spreadsheets with no real idea of how to identify and correct bugs. They *only* advantage the user has it knowledge of the data. (Which *is* a good thing, granted.)
Further, an access database represents an island of information. They are difficult to connect to the rest of the business knowledge base. They are usable only to one or a few people. This feeds into recreational empire-building.
And the worst part: businesses make actual *business decisions* based on these flawed islands of data.
But, it's up to management to figure out which data is "business-critical," and try to ensure that data is managed by data management professionals. Sure, not all data needs that kind of care. But I'd wager most *interesting* data does.
Microsoft is to software what Budweiser is to beer.