Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

The Fine Line Between Security and Usability

Posted by ScuttleMonkey on Mon Nov 19, 2007 06:25 PM
from the discarding-old-tech dept.
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."
+ -
story

Related Stories

This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • In my opinion (Score:4, Insightful)

    by moogied (1175879) on Monday November 19 2007, @06:27PM (#21414205)
    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.
    • by actiondan (445169) on Monday November 19 2007, @06:33PM (#21414279)
      Microsoft is a company, there goal is profit. ... not making linux geeks smile

      Explain Vista then.
    • Re: (Score:3, Insightful)

      Where else should the line be drawn? Unfortunately there is no line nicely "between" usability and security, because the two are in direct conflict. Computers would be so much easier to use in every way if we didn't have to worry about abuse - it's a huge part of the configuration burden that plagues computers today. That's the world we live in. The line has to be drawn somewhere, but "absolute security" isn't it (and neither is "absolute convenience").

      Whether Microsoft draws it at the right place is

    • Re:In my opinion (Score:5, Insightful)

      by jmv (93421) on Monday November 19 2007, @06:56PM (#21414531) Homepage
      That's what really bothers me about the libertarian-neocon view on corporations. You have at the same time:

      1) Companies are only there to make a profit and don't have to care about things like environment, security, ...

      2) Regulation is evil, let the companies do whatever they like and the market will sort it out.

      Logical conclusion from 1) and 2) is that we're pretty much screwed and back to some kind of feudalism. And no, most people do not vote with their wallets and the Market will not sort it out magically (otherwise, CO2 emissions would already be on the way down and there wouldn't be all these environmental problems).
        • Re: (Score:3, Insightful)

          the problem with capitalism (the system you're pretty much describing, not libertarianism)

          I don't believe it's a fundamental problem with capitalism itself. It's a problem with *unregulated* capitalism.

          clueless morons who'd rather follow Big Corp's marketing dept. instead of educating themselves about the issues that affect them

          Unfortunately, that won't be fixed unless the govt were to spend at least the same amount on advertisement as Big Corps to, which is highly unlikely (and possibly undesirable anyway)
    • Re:In my opinion (Score:5, Insightful)

      by mrbluze (1034940) on Monday November 19 2007, @07:07PM (#21414631) Journal

      Microsoft is a company, there goal is profit. Not security, not saving the enviroment, not making linux geeks smile.

      As correct as you are, there does not need to be a fine line between usability and security. There needs to be (and of course there will be) an ongoing evolution in software design to offer usability without compromising security. I reckon it won't be a long time before any software program that gets run in userspace (or any space) has to go out on bended knee requesting to do anything - forced to abide by a security policy by default which limits its access. I don't mean the old broad-brush users/groups/device permissions etc. model that is everywhere now, but stuff like "only allowed to read from this folder, only allowed to talk to this or that application, etc." with very low level behaviour controls.

      I don't think this needs to result in a "the mouse pointer wants to move, confirm/deny" scenario, but that the software designers need to submit with their product a security policy within which their applicaton has to function. The user should be able to very easily browse this policy and see what the program expects to be able to do, and override things, such as "access the internet using HTTPS at port 3232 to server www.phonehome.net" or sloppy things like "read contents of /etc recursively" instead of "read contents of /etc/mostlyharmlesswidget/config".

      I know things like this already exist and there is a limited implementation of it, but to me that just confirms the point that it is the obvious next step.

    • Re:In my opinion (Score:5, Insightful)

      by fm6 (162816) on Monday November 19 2007, @07:08PM (#21414635) Homepage Journal

      Microsoft is a company, there goal is profit.
      So what? You think there's no connection between security and profit? Next you'll be telling me that Ford's goal is profit, not reliable cars. Of course, nowadays they have neither...

      This whole discussion is based on a faulty premise, that MS is leaving its Access users without a fix. They have a fix, and they've had it for some time: stop using MDB format and convert your databases to a data engine that isn't a POS. They've deprecated MDB and Jet Engine. That means they're telling their customers "Don't use that stuff any more, it's faulty." The fact that they continue to support customers who ignore the deprecation doesn't change that.

      There is the little detail that Access itself is a POS. But that's designed in — not much they can do about that.
  • by damn_registrars (1103043) on Monday November 19 2007, @06:29PM (#21414239) Journal
    Mordac, the preventer of information services, makes a statement on security versus usability:

    http://dilbert.com/comics/dilbert/archive/dilbert-20071116.html [dilbert.com]
  • by rickb928 (945187) on Monday November 19 2007, @06:34PM (#21414281) Homepage
    ... that Microsoft doesn't want to fix Jet.

    They'd rather you re-wrote your app and used MSDE, or something with .NET in it.

    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.

    • I hope we re-write our app in mySQL
      Thems're fightin' words around here...
    • A pox on them all. I hope we re-write our app in mySQL.

      If more people share this attitude it will become "profitable" for Microsoft to fix this.

      If not, well, you will have a secure app anyway, and MS can bugger off and die in a gutter somewhere, and all the dumb bastards that decided to rely on a free piece of software from a company with a horrible reputation for customer support and secure coding practices get what they deserve!
      • by berzerke (319205) on Monday November 19 2007, @07:43PM (#21414931) Homepage

        ...all the dumb bastards that decided to rely on a free piece of software from a company with a horrible reputation for customer support and secure coding practices get what they deserve!

        Except with the Internet and massive databases floating around, we are all interconnected. Jet DBs may not be massive, but that doesn't mean the company doesn't have access to other real databases. OK, so the stupid company gets owned. Now, if they have any info on me, that's in the criminal's hands, and good luck getting compensation even if the company admitted full responsibility. Their Internet connection can now be used to spam or DOS me. If they go out of business, think about all the employees who had nothing to do with the IT decisions (and those who opposed this particular one). They get to stand in the unemployment line. Vendors might get shafted on unpaid invoices.

        Just because your system is secure doesn't mean you don't get affected by someone else's insecure system. And no, I don't know what the solution to that problem is.

    • keep using access? It is so dinky as a relational database... I'm not honestly sure what it *is* supposed to be used for.
      • by mfnickster (182520) on Monday November 19 2007, @07:10PM (#21414647) Homepage
        > 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! :)
        • "Access is the path to the dark side, for Access leads to SQL Server, and SQL Server leads to suffering."
            • Re: (Score:3, Insightful)

              SQL Server is [...] the best thing that MS sells.

              Damning with faint praise.
        • Re: (Score:3, Interesting)

          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 d
          • Re:why do people (Score:5, Informative)

            by ronabop (520121) on Monday November 19 2007, @11:37PM (#21416699)
            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.

            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. ;)
        • Re: (Score:3, Insightful)

          This puts you onto the path that will eventually lead to you buying MS SQL Server.
          Or installing SQL Server Express for free?
      • Re:why do people (Score:5, Insightful)

        by kelnos (564113) <bjt23 AT cornell DOT edu> on Monday November 19 2007, @07:12PM (#21414675) Homepage
        Unfortunately, with Access, it's not about the database itself, but about the GUI tools that many people find easy to use...
      • Re:why do people (Score:5, Insightful)

        by TheRaven64 (641858) on Monday November 19 2007, @08:07PM (#21415145) Homepage Journal
        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 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 :)
        • depends on a particular version of Access

          There, fixed that for ya....

    • Re: (Score:3, Insightful)

      I hope we re-write our app in mySQL.

      If Jet was adequate, you may be better off using SQLite.
      • Re: (Score:3, Insightful)

        MOD PARENT UP. I'm not sure which Microsoft product I'd recommend replacing with MySQL. Actually, I'm not sure what use I'd consider for MySQL.

        If JET is adequate for your needs, SQLite is likely to be much better. If you are using SQL Server then you would be better off considering PostgreSQL as a migration path than MySQL.

    • Re: (Score:3, Interesting)

      I don't know. It seems to me that whoever did the triage screwed up. This is not unusual. I remember working at Microsoft and running into issues getting a number of issues fixed. However, the organizational structure of the company often makes it impossible to get problems fixed because nobody wants to act as a cost center for the security (passing the buck).

      When I worked at Microsoft, I remported what I felt was a serious security flaw. Despite the fact that the exploit I remorted resulted in one of
  • do users care? (Score:4, Informative)

    by larry bagina (561269) on Monday November 19 2007, @06:35PM (#21414303) Journal
    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.
    • Re:do users care? (Score:4, Insightful)

      by cdrguru (88047) on Monday November 19 2007, @06:58PM (#21414545) Homepage
      Source code escrow was far more interesting in the late 1980s when some folks actually believed that if they paid for an application (and often a substantial fraction of its development) that they should have access to the source code if the author wasn't available. Part of this came from companies that got burned by the author abandoning their work for one reason or another. Part of it was also that it was a marketing tool - see, the source code can be gotten...

      Today that fantasy has mostly dispersed. Most companies know that if they don't develop an application internally they are at someone else's mercy. There are fewer failures of larger software publishers but even the larger ones sometimes abandon some application leaving the users in a bad spot. But having the source for a 150,000 line (or more!) application doesn't mean a company could compile it, much less fix a serious bug. In general it would take someone a long time to get familiar enough with something like this to be able to work on it with any degree of confidence. Especially a company with a mission-critical application needing a bug fixed - it would take months, often paying a consultant $150+ an hour.

      The "new" strategy seems to be:

      1. deal with larger, established companies whenever possible and hope their user base is large enough that they can just keep pushing out updates and have the product remain revenue-positive.
      2. Write off stuff that is abandoned because it is cheaper to switch to something else than try to independently resurrect something dead.
      3. Never ever do anything internally that could possibly be bought as off-the-shelf.

      Mostly, this is a lot smarter than the late 80s strategy.

  • It's a very old technology. No new projects start with Access in its heart.
      • Re: (Score:3, Informative)

        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 [wikipedia.org] at Wikipedia. Particular note the difference between ESE and Jet Red [wikipedia.org].
  • voting (Score:5, Informative)

    by 99BottlesOfBeerInMyF (813746) on Monday November 19 2007, @06:39PM (#21414349)

    Umm, isn't that the format used in the most popular voting machines to store all our votes?

  • This doesnt matter (Score:4, Insightful)

    by hcmtnbiker (925661) on Monday November 19 2007, @06:44PM (#21414417)
    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.
      • Re: (Score:3, Informative)

        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 'c
  • by Volante3192 (953645) on Monday November 19 2007, @06:47PM (#21414437)
    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?
  • by flaming error (1041742) on Monday November 19 2007, @06:50PM (#21414469) Journal

    some web servers could be at risk if users upload a malicious .asp / .mdb file and then execute it via calls to "ADODB.Connection".
    Servers could be vulnerable to attack if they allow users to upload and run malicious code? Say it ain't so!
  • Almost all other OSS model vs proprietary model arguments are at least somewhat fuzy. Ethics and economics often seem to be in conflict. In many cases neither is tested or clear and we can't even agree on what goes in the pro and what goes in the con columns for each model individually. This case though highlights the fact very clearly that even if all software in your stack is not OSS at least the platform and common libraries should be.

    JET is a depreciated platform and is no longer being actively devel
  • The "article" submitter is only trying to drum up hits to his blog. When it's this obvious, I don't even bother clicking through.

    Perhaps it wouldn't solve everything, but IMHO not directly linking the submitter's name to a non-slashdot URL would greatly limit the article spam on here. And, of course, not letting someone use slashdot to blatantly toot his own horn would limit the practice further.
  • Not a big deal... (Score:5, Informative)

    by Vthornheart (745224) on Monday November 19 2007, @07:24PM (#21414781)
    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.
  • by RipSlider (923376) on Monday November 19 2007, @07:42PM (#21414927)
    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.
    • Re: (Score:3, Insightful)

      Read at least the first paragraph before spreading more FUD. This is NOT a security problem as many pointed out here.

      "allowing for arbitrary code execution once the victim interacts with a malicious JET-dependent file (such as an Access file)."

      It is crazy. Like saying you downloaded a malicious .so file, installed it and it caused a security problem and the OS should not have allowed it. If you download malicious JET files, well, these tend to have code in them that can cause problems. DO NOT do that. So, t
  • by gmuslera (3436) on Monday November 19 2007, @10:31PM (#21416241) Homepage Journal
    Security
    ---------------------
    Microsoft

    Was that so hard?
  • by Xoc-S (645831) on Tuesday November 20 2007, @12:50AM (#21417065)
    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.
    • That's stupid. That's not how any other industry works.

      All sales are final, ever heard of it? Perfectly acceptable and legal. If you don't do due diligence before you buy the responsibility is yours. It just so happens providing support is USUALLY in the best interests of both parties. Hence why manufacturors offer limited warrenties for certain durations. Fixing 10 year old code is a net negative for the manufacturor: not doing so does not loose them enough sales to offset the cost.
      • 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 man
    • 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 d

      • Re: (Score:3, Insightful)

        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 :)

        The amount of support you get generally depends on how much you are willing to pay for it. This cost will go up as the product becomes less mainstream. The upper limit (when you are the only organisation using it) is employing a team of people to become familiar with the code and fix bugs. This is likely to cost a couple of hundred thousand dollars a year, but if you are running a multimillion dollar business on some in-house software that depends on something external, then it may be worth it. It's mo

    • by TheRaven64 (641858) on Monday November 19 2007, @08:04PM (#21415121) Homepage Journal
      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.
    • 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 databas