 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
MS Access Forum / Security / May 2008Vulnerability in Microsoft Jet Database Engine Could Allow Remote
It appears Microsoft released a service pack update last night that includes the following as a part of the service pack: MS08-028 Severity Level: Important Vulnerability in Microsoft Jet Database Engine Could Allow Remote Code Execution (950749) It appears that after this service pack was applied at many of our customer sites (who apparently have automatic updates turned on). that all of our customers can no longer get into one of our primary forms, our Order Entry form. Because we have made absolutely not changes to our software we have concluded this update is the source of the problem and have in fact proved it. We had one of our customers do a restore proint, that removed the update and our product works fine now, which has been in use for over 10 years now. Anyway, has anyone heard about problems arising because of this update and if so, what are some of the solutions to allow our MS Access product to work with the service pack applied? Thansk Greg Could you provide some specific details? i.e. What Operating System? What version of Jet did you revert to (if you can check the version of Jet after the update, and what the version is after you restore that would be a help)  SignatureJoan Wild Microsoft Access MVP : It appears Microsoft released a service pack update last night that includes : the following as a part of the service pack: [quoted text clipped - 20 lines] : Thansk : Greg Are you sure it is MS08-028 causing the problem, rather than -026? Is that an Access form? Or a VB form? Word? Excel? You've made no changes in the last 10 years? That means you are using Access 97/ Jet 3.51? Or do you mean that you only updated to new versions of Access? Which version of what software are you using? (david) > It appears Microsoft released a service pack update last night that > includes [quoted text clipped - 25 lines] > Thansk > Greg Sorry I did not provide enough details, but since I posted we have come with a solution, but I am still confused as to why this has happened in the first place. Anyway, the database I am referring to was started in MS Access 97, but has grown over the years and is now developed in MS Access XP/2002. All of our customers who stopped working were running Windows XP Pro. Initially, we had to have all of our customers do a System Restore to the previous day and turn off Automatic updates as a short term fix to get our customers up and running, since we had no idea why our software worked one day just fine. I really am not comfortable with making our customers have to do this. But after the service packs were applied, either Windows XP Pro/Home Service Pack 3 and/or MS08-028. Both of these rendered our software broken in just a single form (and of course it was the most important form: Order Entry - and Job Ticket creation). Anyway, it turns out this service pack prevented one out of several hundred queries broken. The error message said something about not finding a database to some degree. The query mearly returns a recordset with two tables joined. The solution was to delete the query from the database and then I completely created a brand new one and made aboslutely no changes. Actually, I copied the SQL from the original query into the new query. This had to be done on a machine that did not have the service packs installed. Then, when we put the application back on the Service Pack 3 computer it now runs fine with no errors. What concerns me though is that the query functions and can be viewed in design view just fine prior to the service pack, but appears currupt after the service pack. Why would a service pack, such as the ones I'm referring to cause a query to stop working, even though it runs fine and can be viewed in design view prior to the service pack update? Anyway, we are back in business now, after a whole day of lost productivity and a lot of angry customers. But, I would like to understand why this happened at all and what is it the service packs are doing that would make a perfectly good query useless afterwards. Any light that can be shed on the Service Pack issue would be helpful. I just want to understand what is going on more than anything at this point so I can understand why one of our queries would become broken after a service pack update so that I can be pro-active for our customers in the future. Thanks, Greg > Are you sure it is MS08-028 causing the problem, > rather than -026? [quoted text clipped - 37 lines] > > Thansk > > Greg Are the joined tables in your query remote tables (Sql Server, Oracle, ...) or are they tables stored in the Jet database? It sounds like your query needed to be recompiled after installing the service pack. If the query goes to remote data, has anything changed on the remote server or DSN, such as a server upgrade, table schema change, etc? I don't know what caused the query to need to be recompiled (if that was the case) but something like that could trigger it. Also, on a test machine you might try compacting the database after upgrading to XP SP3 and see if the query works after the compact. Lastly, in design mode after applying SP3, what appears to be corrupt? Thanks, -Curtis > Sorry I did not provide enough details, but since I posted we have come with > a solution, but I am still confused as to why this has happened in the first [quoted text clipped - 85 lines] > > > Thansk > > > Greg We have our software installed on about 300-400 individual computers throughout the country and Canada. We’ve had the same .MDE compiled fully functional application running fine at our customer sites for the current version for over 18 months with no problems. All of the sudden yesterday we were getting dozens of phone calls that our software stopped working for no reason, other than the Microsoft Windows XP Service Pack 3 release or the Security Release for MS Access was installed on our customer’s computers. I am still concerned that we have many, many customers who have yet to have the Service Pack installed, which will result in another nightmare of a day for our company. The suggestion that we have to recompile our application using a machine using Service Pack 3 is a fine solution if all you have is a few local computers to take care of, but to have to role out an update for hundreds of computers is quite a different story. Our customers can’t stand upgrades as it is, much less have to apply an update to solve a Microsoft Service Pack problem. What I’m looking for is reason why Microsoft’s Service Pack releases would render our software useless, when it has been functioning just fine for over a year. The only solution we had for our customers yesterday (for immediate response purposes) was to have them do a System Restore to the previous day to remove the Service Pack 3 update. After customers removed the Service Pack 3 update, our software resumed working just fine, with no changes on our part, so something in the Service Pack 3 update clearly did something it shouldn’t. Also, this will now result in our customers having to update our software now and then have the service packs reapplied manually. That will be an utter mess. What I’m looking for is an explanation as to why a service pack release would render our Microsoft Access software dead in the water, after it’s been running fine for so long. We are getting ready to do a major upgrade release in about two months and I would like to learn what this Service Pack is doing to our software so that we can resolve any Service Pack 3 related issues “before” we role out our update. I wish I had more specifics other than that one of our queries was all of the sudden perceived as bad after the Service Pack 3 update. I don’t know how much more detail I can get into other than that. And, what really scares me is the fact that our repair was merely to delete the query and recreate it and bingo it runs fine under Service Pack 3. That just scares the heck out of me, so that’s why I’m looking for a “reason” why Microsoft’s Service Pack would do this to our Access software package, which is a valid and compiled version of MS Access database as an MDE. It’s either a problem with the Service Pack or a problem with MS Access. Where would I report such a problem to Microsoft (where someone would actually respond to me about this serious problem) so that I can get the information I need to make sure we don’t end up with dozens of customers with hundreds of computers that stop working because of a Service Pack release. I just want to try and be pro-active so we don’t have a catastrophe like this again in the future. This whole situation has reflected very poorly on our company as it looks like we screwed up, but in reality, it is something Microsoft did while everyone was sleeping that caused our software to stop working. I need some insight on how to find out what the problem really is, and how I can avoid such a disaster in the future. And, I know the information I am providing seems too simplistic, but our software basically did stop working because the Service Pack 3 update decided it did not like one of our queries. And, I’ve looked at the query too. It’s one of the most basic and simplest queries we have. It simply joins two valid tables (with no schema changes) and outputs all of the fields. Can’t get much simpler than this. Anyway, if I’m sounding a bit frustrated and upset, it’s because I am. This whole disaster has cost our company a pretty penny in monetary terms and in terms of our reputation in the industry now. What will those costs end up being? > Are the joined tables in your query remote tables (Sql Server, Oracle, ...) > or are they tables stored in the Jet database? It sounds like your query [quoted text clipped - 101 lines] > > > > Thansk > > > > Greg Greg, could you email me please. jwild at tyenet dot com SignatureJoan Wild Microsoft Access MVP : We have our software installed on about 300-400 individual computers : throughout the country and Canada. We’ve had the same .MDE compiled fully [quoted text clipped - 174 lines] : > > > > Thansk : > > > > Greg =?Utf-8?B?R3JlZw==?= <AccessVBAnet@newsgroups.nospam> wrote in news:1320D13E-5CB4-4ED5-9E91-405CFA18D9AB@microsoft.com: > We have our software installed on about 300-400 individual > computers throughout the country and Canada. Weâve had the same > .MDE compiled fully functional application running fine at our > customer sites for the current version for over 18 months with no > problems. You seem to be misconstruing Larry's advice about query compilation to refer to VBA code compiling. That is not what he was talking about. He's talking about the compiled query plan, which is created each time you save a query. If you compact a front end, all queries are marked to be recompiled the next time they are run. If the query compilation was the trigger for the problem, then a compact of the MDE would have caused the problematic query to be recompiled the next time it was run. Again, this has *nothing* to do with compiling VBA code. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ If the problem is just with one query, at least you won't have to update your software. Just compact the database. You can provide a script to do that. (david) > The only solution we had for our customers yesterday (for immediate response > purposes) was to have them do a System Restore to the previous day to remove [quoted text clipped - 8 lines] > the query and recreate it and bingo it runs fine under Service Pack 3. That > just scares the heck out of me, so that's why I'm looking for a "reason" why > Microsoft's Service Pack would do this to our Access software package, which > is a valid and compiled version of MS Access database as an MDE. It's either > a problem with the Service Pack or a problem with MS Access. =?Utf-8?B?R3JlZw==?= <AccessVBAnet@newsgroups.nospam> wrote in news:8F7E9288-2F4F-48E9-8629-6103CED03496@microsoft.com: > Why would a service pack, such as the ones I'm referring to cause > a query to stop working, even though it runs fine and can be > viewed in design view prior to the service pack update? If deleting and recreating the exact same saved query corrected the problem, it suggests that it was somehow caused by the compiled query plan. If you have the problematic MDB that still causes the problem, try compacting it and see if it then runs. If so, then the compilation was definitely your culprit. That won't explain *why* it was a problem, though. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ If I remember correctly, the security patch is supposed to block "certain malformed queries". It's not entirely surprising that some legitimate queries might get caught. I take some consolation from the rumour that this service pack was pulled because it broke a MS ADO application. (david) > Sorry I did not provide enough details, but since I posted we have come > with [quoted text clipped - 108 lines] >> > Thansk >> > Greg Hello, > It appears that after this service pack was applied at many of our customer > sites (who apparently have automatic updates turned on). that all of our [quoted text clipped - 5 lines] > it. We had one of our customers do a restore proint, that removed the update > and our product works fine now, which has been in use for over 10 years now. We are currently fighting a very similar issue -- Existing application no longer working reliably after JET update. We have not been able to actually reproduce it in a development/testing environment which is making our frustration level high. As of Wed we started getting a flood of customer complaints stating that their application database became corrupt -- which prevents the application from reopening. We restored from backups as the complaints came in, but then we found that facilities we even restored were calling back later to say that it happened again. Rinse and Repeat. We feel we are being bit by this update as 100% of the call-ins have had that update applied (all are SP2 XP). We do not control the client computers, so it's impossible for us to "pro-actively" jump onto client computers and blacklist the update. We are really at a loss here. :( We do not have any "embedded" SQL statements in the database (as was mentioned in this thread). All access is done via inline queries in the VB6 code. I know this isn't enough information to actually debug anything, but I just wanted to also chime in with a "us too" so that voices can be herd on this issue. That said, if anyone does know what is going on or has any tips on debugging this, it would be much appreciated. For what it's worth, not a single customer that called with this issue was doing the exact same thing... they all were just using the application like normal with no usage pattern to be found. Cheers, Chad Kittel iit/SourceTech chad.kittel@gmail.com |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.