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."
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?
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
Hint: You don't have to be a programmer to find a bug.
Hint: Just because he haven't fixed any bugs, or even found any, doesn't mean he can't pay someone to do it for him.
Hint: You try that with $PROPRIETARY_VENDOR
Hint: You're an idiot.
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.
Exchange Server never used the Jet that Access uses.
It used something that originated as DAE, and whose team and query engine was merged for a brief period with Jet Red (what Access uses).
But the ESE (sometimes called Jet Blue, even though it has almost nothing to do with the Jet that Access uses) used by Exchange and Active Directory is not that Jet you're talking about.
2 minutes of search on wikipedia for 'jet blue' or ese will clear this all up for you. In particular, read the History section and the 'comparison to Jet Red'.
Stimpy, sometimes your wealth of ignorance astounds me.
.mdb file, you've already won, there is no need to do any stack overflow bulls*it. It's an *executable* file format, you idiots.
Microsoft won't patch this because the Jet format already allows for column type definitions that execute callbacks to calculate the value.
http://msdn2.microsoft.com/en-us/library/ms684489.aspx
If you can trick someone into opening a malicious