12 replies to this topic

[pstein]

When I open Autopatcher in 64bit Win7 then in section Security Updates a black entry is listed for

KB982666

with a check in checkbox in front.
All other current security updates were already applied successfully and appear in blue.

Ok, I click "Next" and applied the update KB982666. Autopatcher seems to copy something.
I reboot. But then - much to my surprise - the update in questions is still in black and seems to be NOT installed.

Why?

Peter

[Cristiano]

this one i was able to check easily, because i'm running 7x64 as well. let's see the picture:
- KB982666 is an update for an component of 7, IIS;
- that component may or not may be installed. if installed, the update will apply. if not, the update will fail;
- as all the updates are silently deployed, the user will not know the reason for the failure

it's possible avoid that issue? in a certain way it is and in a certain way isn't. let's me clarify: an restriction could be added into the module, avoiding this one be loaded, if IIS isn't installed. an possible check for that is checking for authsspi.dll, that (if present), is located at Windows\System32\inetsrv. the problem: autopatcher is an x86 app and can't reach that folder. i've tried a dozen of times locate another suitable detection for that, but i didn't found any

the problem: those that has IIS will have that vulnerability and require that update. but for all the other ones, this update always will show as not installed (and isn't, because the issue isn't present and the load of the module can't be avoided as well)

[]s

[pstein]

Cristiano, on 03 January 2011 - 10:45 PM, said:

this one i was able to check easily, because i'm running 7x64 as well. let's see the picture:
- KB982666 is an update for an component of 7, IIS;
- that component may or not may be installed. if installed, the update will apply. if not, the update will fail;
- as all the updates are silently deployed, the user will not know the reason for the failure

it's possible avoid that issue? in a certain way it is and in a certain way isn't. let's me clarify: an restriction could be added into the module, avoiding this one be loaded, if IIS isn't installed. an possible check for that is checking for authsspi.dll, that (if present), is located at Windows\System32\inetsrv. the problem: autopatcher is an x86 app and can't reach that folder. i've tried a dozen of times locate another suitable detection for that, but i didn't found any

Interesting. Yes, I have the folder Windows\System32\inetsrv but no files inside.

Why is it impossible to reach this folder from a x86 app? From my point of view every x86 prgm can list every directory content on the hard disc.
Furthermore it can setup a "run at startup" entry in the registry where a batch script can be called which in turn can copy *.dlls into certain folders at next reboot.
Other x64 *.dlls can replaced as well.

Anyway. If that all would not work Autopatcher could (should !) make a statement to the user for this issue. It should either popup a notification dialog or write a log file telling something like "Unable to apply this issue because...."
In addition it should grey out this entry in order not to confuse the user with unapplicable updates.

What do you think?

Peter

[Cristiano]

> Why is it impossible to reach this folder from a x86 app?
because autopatcher has an built-in routine to identify certain key folders, like system32. the problem is that x64 systems has system32 and SysWOW64. to x64 softwares, the OS send the proper folder (system32), but to x86 software, it sends the folder that was designed to x86 software: SysWOW64. we can't be sure that the inetsrv that is also inside that path isn't empty if an x64 user has IIS. i don't remember right now if i've already tried detect something in that folder to be sure that an detection targeting that folder will works. the same problem also happens to registry detections under x64 systems. due that, most of the x64 modules has the detection restricted to something like this:
FilePath=windows:\system32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}
FileName=Package_for_KB975467~31bf3856ad364e35~amd64~~6.1.1.0.cat

due some reason that i'm not sure why, x64 OS's allow x86 softwares reach CatRoot, but only that. we can't even take detections based in md5 or file versions in certain key folders. for registry, it's even worst... an update that applies both to x64 and x86 systems should have the same detection, but no, the OS redirect HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall to HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall, breaking the detection. sometimes, it's possible bypass that limitation by targeting another location from registry, like HKCR\Installer\Products\EE34577E5BF66FF4BA073635298C7C65 but isn't everything that goes in there. most of the times, the version of something is written in that section in hexa and autopatcher was build to read decimal. by instance, take a look in the registry entry that is taken for the detection of Microsoft Security Essentials x64:
RegistryPath=HKCR\Installer\Products\EE34577E5BF66FF4BA073635298C7C65
KeyName=Version
KeyValue=33555089

if you look into the registry, the key value in that location is 2000291. if you forget about convert the notation, then the detection doesn't work

about popup, autopatcher hasn't that feature. the same thing with the install log. in fact, it should be re-written, to bypass several limitations that we have today, but that takes an time that our developers doesn't have (please, remember that they work for free...)

but i will talk with domenico. perhaps an warning at the module description could help...

[]s

Edited by Cristiano, 04 January 2011 - 10:53 AM.

[_def_x_]

Quote

perhaps an warning at the module description could help...

The descriptions need serious work if they're to be of any use. I would quit using generic statements like these...

Spoiler

A security issue has been identified that could allow an authenticated local attacker to compromise your system and gain control over it.

A security issue has been identified that could allow an unauthenticated remote attacker to compromise your Microsoft Windows-based system and gain access to information.

These 3 patches use one of the statements above when a much better description can be taken from the security bulletin, one that's shorter and more informative.

Spoiler

Vulnerabilities in TCP/IP Could Allow Elevation of Privilege (978886)

Vulnerability in Internet Information Services Could Allow Remote Code Execution (982666)

Vulnerability in Microsoft Windows Could Allow Remote Code Execution (2385678)

Also, a Read_Me_First_txt file might help, containing important information about problematic updates, like KB982666, whose fix is not a simple one. Maybe something like this...

Spoiler

January 2011 Patch Tuesday Warnings & Notes:
...KBxxxxxxx - important information here - warnings - workarounds etc
...KBxxxxxxx - important information here - known fix, etc

June 2010 Patch Tuesday Warnings & Notes:
...KB982666 - important information here - warnings - workarounds etc
...KBxxxxxxx - important information here - known fix, etc

Just my $0.02

[Cristiano]

well, that it's more easy to explain... ms us to enforce the language that is set by default in your browser and redirect the user that tries reach the security bulletins by the version that was badly translated by an machine. if i set english by default, then several pages that i go every day will turn into english by default as well and sometimes it changes the content of the pages as well (news about US instead BR, by instance). if i don't do that, then to take that description i have to force the load of the english version for each update. due that, i us to take the description that is set at ms download site, that us to have the same description to every single update (and at this one, i just have to choose the language of the update that i wish to download, instead change the language once and in the following link, change again to the default language - aka the "translated" version). from times to times, i'm surprised seeing an "fix the security issue described in ms-xx" instead the generic description. if i'm not mistaken, ms does that to make an easy translation (set the proper translation once and just replace it next month). i us not to care too much about that, because there's an link to the description of the issue in every update, but i will try remember that

but in deed, that idea about an readme file could work with the x64 versions (that are the versions that us to have this kind of issues)

[]s

[_def_x_]

Quote

there's an link to the description of the issue in every update

True, but this is little help if your're doing a fresh install, kinda takes AutoPatcher back a step or two not knowing anything about the purpose of an update when both the title and description give no details. If your're going to have to visit Microsoft to learn what it is being installed might as well use MU to do the installation.

Anyway, I understand these translaters are not great but it's a shame that AutoPatcher and the user have to suffer because of it.

Btw, maybe an html file would be better than a text readme, you could have clickable links, a much more dynamic file type over txt, it would load in the user's browser when clicked - just an idea

[Cristiano]

and will happen the same issue than happens with WSUS... ok, i've got the idea

[]s

[_def_x_]

Quote

and will happen the same issue than happens with WSUS... ok, i've got the idea

Sorry, I was not trying to nitpick or complain, rather simply offering constructive criticism. The truth be known, I have said many times I no longer use AutoPatcher and the 5 or so people I recruited to the program as well have since been using a program that my friend developed two years ago. My main reason for being around is to help keep the project moving forward by offering an opinion ... (I've said time and again I know I'm nothing important around here and don't care to be ) ... but not if it seems I'm only here to cause trouble.

It's all cool, run the project as you see fit

[dkdk_it]

Hello,
I've not understand this:

gUiTaR_mIkE, on 05 January 2011 - 10:25 AM, said:

Anyway, I understand these translaters are not great but it's a shame that AutoPatcher and the user have to suffer because of it.

Where is the problem? There is a link in each hotfix description reachable by "More info" (below right)... this link directs you to MSXX-XXX page about the hotfix.
So?!? The real shame is to accuse the only 2 persons that still are following this project!

I'm thinking a solutions for KB982666. I need more time because I've a work and a life... and I would like to sleep 7-8 hours for night instead of 3-4!
Please be patient.
Thx.

[_def_x_]

Quote

So?!? The real shame is to accuse the only 2 persons that still are following this project!

What are you talking about, accusing who of what? A translator is software not a person, you type a sentence in English into and you ask it to translate to 'X' language. In many cases the translation is very generic and unhelpful and wrong in tone.

[_def_x_]

Quote

only 2 persons that still are following this project!

There might be a reason for this as well. If a person has to go online to know about an update, this doesn't help with with their new build THAT ISNT CONNECTED TO THE INTERNET NOW DOES IT. You can remove one more from the list of former participants.

[pstein]

dkdk_it, on 15 January 2011 - 01:01 PM, said:

I'm thinking a solutions for KB982666. I need more time because I've a work and a life... and I would like to sleep 7-8 hours for night instead of 3-4!
Please be patient.
Thx.

Ok, thank you. I appreciate your efforts.
But if you think about a solution then do it in a more general way. It could happen frequently in the future for other updates as well that certain patches are not applicable because of not existing components.

Peter