I also create my own setups manually. I do not use MSMs. But I am very curious about this whole subject.

On my PC, I've got Windows XP, sp2 (and the latest critical patches to date).

In my WINDOWS\SYSTEM32 folder:

GDIPLUS.DLL - 5.1.3102.2180 (dtd Aug 2002)
GDI32.DLL - 5.1.2600.2180 (dtd Aug 2004)


And in my WINDOWS\WINSXS folder, there are three subfolders related to GDI:

x86_Microsoft.Windows.CPlusPlusRuntime_6595b64144ccf1df_7.0.0.0_x-ww_2726e76a
x86_Microsoft.Windows.CPlusPlusRuntime_6595b64144ccf1df_7.0.10.0_x-ww_d8862ba3
x86_Microsoft.Windows.CPlusPlusRuntime_6595b64144ccf1df_7.0.2600.2180_x-ww_b2505ed9

It seems like I have the latest version of GDIPLUS.DLL but I am puzzled as to why the date stamp on the file is still 2002. Whereas the date stamp on GDI32.DLL is 2004. (I believe that came from sp2.)

I reaaly don't know the purpose for those three folders WINDOWS\WINSXS. Does anyone know?


As John has stated, the real question is knowing what needs to be shipped to a user's PC. And is there going to be a new MSM.

I think we do need to worry about it. Although an end user who is running our VFP apps might not trigger a JPG buffer overflow, as I understand it, the act of installing one of our apps can introduce the GDI vulnerability to that end user's PC which may then be triggered through a browser (or whatever else).

Doesn't this give the whole development community the jitters? I don't mean just VFP. I also mean VB, VC, Delphi, etc. This is extremely important isn't it?

Guy





>>>We are bombarded with critical warnings about the GDI+ buffer overrun exploit but the response from Installshield and MS is somewhat underwhelming if one wants the logical solution for distribs, i.e. a new MSM build.
>>>
>>>I have downloaded a new build of GDIplus.dll (5.1.3102.1360) from http://www.microsoft.com/technet/security/bulletin/MS04-028.mspx so what's the go now?
>>
>>Fox is not mentioned on that page... don't know whether we should worry at all :).
>>
>
>Dragan
>
>'Our' build, i.e. the one installed with VFP8 and the one in the MSM that accompanies VFP8, is 5.1.3097.0 which is branded as insecure on the MS security bulletin site.
>
>Yes, we should worry about it! As I said in my full post, it may not be the case that an app is expected to encounter one of the 'carefully crafted' JPGs that allegedly make the exploit work, but in my experience system administrators don't want to know that stuff anyway. When they look for someone to blame after a security lapse, I want to plausibly claim my app is squeaky clean.
>
>John Burton :)