back to article Attackers hose down Microsoft's Jet DB Engine

Microsoft has admitted that it was first aware of bugs in its Jet Database Engine way back in 2005, but decided not to patch the problems because the software giant thought it had blocked the attack vectors. Mike Reavey, a member of the firm’s security team, said on a blog post late Monday that Microsoft had been told by …

COMMENTS

This topic is closed for new posts.
  1. Tom Chiverton
    Stop

    Right...

    'customers should never automatically open a .mdb file “received unexpectedly”'

    Right, except, users are stupid.

    Call it 'open for free hot pron' or 'click here for your competitors details' and watch what happens.

    'New corporate screen saver' used to work well too in certain segments.

    Just fix the damn bug, stupid.

  2. Peter D'Hoye
    Unhappy

    Or as they say...

    ... never let a good workaround come in the way of a real bugfix. Microsoft, as we know them :(

  3. WhatWasThat?
    Jobs Horns

    Never automatically?

    Wait a minute - Word files will pull up the Jet MDB file automatically as it opens if embedded...

    So how is anyone to know if the Word document attachment has an embedded MDB file? Don't you just love MS's OLE legacy?

  4. Brian Miller

    Don't fix, don't tell?

    And Microsoft wonders why it has such a bad name when it comes to security. They know about the bugs. They don't fix the bugs. They don't tell about the bugs.

    And now that world+dog knows about the bugs, they still wonder if they should bother to fix the bugs. Since Vista is OS-non-grata, maybe they should get off their butts and fix it.

  5. daniel
    Boffin

    How about migrating jet (red) to jet (blue)... and...

    ... and remove the 2 Gb size limitation?

    oh, and currently, under office 2007, I can't even access data tables by default due to security settings!

    the problem is that as Access *is* a programming platform, along with all office documents, and that access has an 'autoexec' function, the only way you could stop malicious code being executed is to:

    1) remove the VBA environment, and ship it as a stand alone module: 1 database, 1 VBA project. An access linked project cannot run until it has both database and project available. Having the user load both independant units would mean that the luser is really asking for it ;)

    2) Hardcode a VBA check to refuse to launch any VBA code if the document root is in any temp/tmp/temporary internet files directory: the VBA environment would only work after saving the project to the hard drive then launching it.

    Mix both, and you would have to save both docs to the main file system, and execute the project. Running (or autorunning through a security hole in browser/email client) would fail due to the temp dirs being no execute: you should only be able to read data, but nothing should be executed from there.

    This would stop other Office documents working as a "dropper", i.e. opening from temp, execing autoexec, dropping another document and executing that with all local rights, getting round any gateway filtering (temporarily anyway) that may be used.

    Taking this a little further, it would really be nice if MS could even mark all Temp/tmp/temporary internet files folders with some sort if NOEXEC flag: not only would it stop this sort of thing (though you could get around this with some crafty social engineering), but would also stop a very large part of internet browser mamlware/spyware/virus installs that generally tend to run from those same temp directories...

  6. Anonymous Coward
    Pirate

    JET is rather more important that they're letting on?

    Isn't JET the underlying 'database' for both Exchange and Active Directory (JET "Black" and JET "Blue" IIRC)?

    This may have changed with Windows Server 2008 and Exchange 2007, but even if it has, there would be an awful lot of vulnerable sites around.

    I hope I don't understand the problem ...

  7. Kanhef

    Boggles the mind

    that they could know about a bug, a possible security flaw, for years and not do anything about it. This is why we have so many rabid Microsoft-haters; the company willfully contributes to the insecurity of the internet.

  8. Anonymous Coward
    Thumb Down

    And the solution is.

    Just get rid of all Microsoft related sofware.

    The company is a mess based on fraud.

    With their PC background they just did not make it.

  9. Geoff Mackenzie
    Joke

    A rabid hater writes

    Why not just have the Windows kernel destroy .mdb files whenever it finds them? They're useless legacy toss anyway. You'd have to be an idiot to use them. It's not like a serious software company would use that cruft as the backend of anything important. :)

  10. paddy carroll

    Conundrum

    Access and Jet are really useful tools, The main problem with them is that they encourage semi literate users to produce half baked solutions to business problems that inevitably become a liability.

    As to whether they are a vuln, well the kitchen knife is a vuln, hell the toilet is a vuln if you stick your head down it; what really gets me going are the "are you quite sure" nags you get every time you open an mdb and no I cant be assed to get SP whatever. Cant we get used to the fact that any useful programming environment represents a threat of sorts; MS seems to have removed them from Office 2008 for Mac ensuring that I will never use that product.

  11. fissuria
    Gates Horns

    Microsoft advices...

    Turning your Windows-based computer opens you to an jungle of viruses the exists out there.

    ...so, go on, turn it off... err, no..

    Ok... we warned you, proceed at your own risk...

  12. Wayland Sothcott

    Access is useful and powerful

    The JET engine is used for the registry I believe. I expect it's used internally for all sorts of OS data storeage.

    One of the reasons for microsofts success has been the lack of security. Having everything really easy to get started means you are likely to do more things. However Microsoft products although powerful and easy to get started with they get harder the more you use them rather than easier.

    The JET engine works really well and usually out performs oracle in single user applications. Unfortunatley this leads you in to developing some very serious business critical applications which by the time you have finished have become both indespensible and a support liability. Over a network with say 30 users the .MDB file will keep corrupting on a random basis. Easy to fix but it will keep an Access developer in work for a decade ;-)

    One of the smart things about the JET engine is it's ability to parse SQL and VB. About 9 years ago we wrote a B2B website for suppliers to collect their orders. Each logged in with their account number and password. However by simply entering code such as '=password' in the password box on the login page, the JET engine would parse the SQL as 'if password=password then let them in'. (psudeo code not real syntax here)

    All that Microsoft power and flexibility can have unforseen consequences, well at lest for our programming knowledge at the time.

  13. Anonymous Coward
    Go

    time to try OSX

    Need I say more? Seriously... switch to OSX or Linux... if you want M$ to finally fix their security issues, this is the best thing you can do. They have little incentive to do anything, when they have a monopoly, but competition always creates better products for the end user.

    True, there is debate among fools about security of UNIX and Linux... but the truth is, these platforms are light years ahead of M$ on security.... so beware, any response to this post, about OSX and security better be documented with real data & empirical statistics. If you cite a rise of viruses for OSX, I want real interviews from those infected. No citations of so called "experts" allowed... only real facts and real life exploits.

  14. Mark Simon

    Sandbox

    A while ago MS Access started to pop up a message about blocking harmful expressions. All that showed is that they have a flimsy approach to security and integrity.

    All scriptable environments should have a sandbox mode, which removes all access to the outside world. That doesn't mean that you can't also have a non-sandbox mode which requires user interaction or digital certification. That's it, problem solved.

This topic is closed for new posts.