Is there a win32 API function which you can use to query if a specific patch has been applied to a user's system? In July 2011, windows patched a dll hijack vulnerability in DirectShow. My program uses one of the dlls that can be hijacked by this exploit, and I would like to warn any unprotected users.
Related
I am working on an installer of a windows application. Due to its dependencies, to make it work, multiple applications need to be installed and also some changes to the windows features (turning on some windows features) are required.
My installer is supposed to be used by companies. In companies, it can be the case that someone has the rights to install software (in program files folder) but is still restricted (for example updates are regulated by the IT department). A typical explanation for this is that someone is a local admin but not necessarily a global admin.
Can it be the case that someone is allowed to install software in the program files folder but restricted in enabling windows features? I need to know this because this would simply mean that my installer should not automatically/automated enable such windows features. It may work on my VM, but it can fail on the customer employee desktop which would cause the installation to fail due to missing rights for one specific action: enabling some windows features.
Can enabling Windows Features be blocked for local admins?
According to this answer there's no group policies to control Windows features. Therefore we could assume that you're safe for now.
I have a Windows desktop C++ application that currently uses ::PathCanonicalizeW. As you can see from the documentation, it was introduced in Windows 2000 and is located in shlwapi.dll. In order to support long paths on Win 10+, I need to start using ::PathAllocCanonicalize (or one of it's friends - ::PathCchCanonicalize or ::PathCchCanonicalizeEx).
This function was added in Windows 8, but I still need to support the older OS's. In order to support all OS's, I need to dynamically load ::PathAllocCanonicalize by calling ::LoadLibrary at runtime. The problem is that the documentation doesn't provide the DLL that includes this function.
After doing some searching, I found this documentation that includes all 3 of the new PathCanonicalize functions and it claims that they are in api-ms-win-core-path-l1-1-0.dll. After more searching, it appears that this is not a traditional DLL because there is no file anywhere in the OS with that name. This application has always loaded system libraries using the full path to the file in the system directory (typically C:\Windows\system32) to make sure that it's not loading malicious DLLs, but for this it will be impossible without a physical file to point to.
I have been able to test that calling ::LoadLibrary("api-ms-win-core-path-l1-1-0.dll") does work, but the fact that that documentation mentions UWP worries me. Is there any documentation for the supported way to dynamically load these kinds of functions at runtime in a desktop app? Is there a more secure way to load this DLL?
P.S. This app cannot be deployed with that DLL, and even if it were possible there's no point since any OS that doesn't have that function wouldn't have full support for long paths anyway. Using the documented pathcch.lib would require upgrading the target Windows version. Dropping support for the older OS's is also completely out of the question. The function must be manually dynamically loaded at runtime.
As pointed out by Hans, api-ms-win-core-path-l1-1-0 is known as an API set along with many others starting with api-ms-win-core. Based on the documentation there, it appears that the documentation for PathAllocCanonicalize is incomplete. It should list the API set on that page along with the DLL for desktop apps. Looking at the source on GitHub, it looks like there is a bug with that page and the other pathcch functions where that information is in the header but not rendered onto the page. That header lists api-ms-win-core-path-l1-1-0.dll and KernelBase.dll.
If for some reason I wanted to continue to load the API set instead of KernelBase.dll, ::LoadLibraryExW(L"api-ms-win-core-path-l1-1-0.dll", NULL, LOAD_LIBRARY_SEARCH_SYSTEM32) worked which would be just as secure as specifying the full path to a DLL in the system32 folder. Note that LOAD_LIBRARY_SEARCH_SYSTEM32 was not supported without KB2533623 on RTM versions of Vista, Windows 7, Server 2008, and Server 2008 R2 so that might not actually be secure on those OS's.
I have created access front end ACCDR from Access 2016. In order for users to use this file, users need to install Access runtime 2016.
Most of my users already have MS Office 2007 or 2010 installed. So, when users try opening the ACCRD file, after install Access runtime 2016. They still get an error as they are opening the file using the older version of Access (aka 2010) and not the 2016 version.
My question:
How to check if the user has the correct version of Access set as default? I am fine with paying for a software which checks this. I am also fine with editing registry if any or importing registry if any.
[ACCDR files are created by renaming ACCDE (Access compiled files)].
You can read the version directly:
Version = Application.Version
Should return "16.0". If not, pop a message to the user to open using Access 2016.
Even better, provide a shortcut for the user to open your app with the runtime.
Best approach would be to query the COM just after you launched the process and act accordingly.
if you don't have an access process already running, just start one, query it, and do your stuff in the process that you just invoked.
Microsoft.Office.Interop.Access.Application _accessApp = new Microsoft.Office.Interop.Access.Application();
string version = _accessApp.Version;
Match the version string against Microsoft's version history:
https://en.wikipedia.org/wiki/History_of_Microsoft_Office
for office 2016, the string you're looking for is 16.0
Another approach is checking the GUID of office via the registry
and comparing it to a known office guids (they aren't random).
https://superuser.com/questions/1140114/how-to-detect-microsoft-office-version-name
I have some free-standing C++ code (i.e. not a Windows program) that needs to identify the version of Windows that is installed on a PC.
I can easily differentiate between the different Windows client releases by kernel version (e.g. GetFileVersionInfo on ntoskrnl.exe), however I'm wondering if there's a reliable way to distinguish between a client and server installation.
A problem arises when using this method to distinguish between Windows Vista SP2 and Windows Server 2008 SP2 (6.0 build 6002 the both of them) and Windows 7 and Windows Server 2008 R2 (6.1 build 7600 for RTM and 6.1 build 7601 for SP2, both). What is a reliable (and preferably as straight forward as possible, avoiding the registry would be great as access to Win32 API is not available) method of identifying client vs server OSes correctly for code running outside the environment?
I suppose I could check for files only present on the server edition (what's a good file guaranteed to be on any server edition install, regardless of configuration?), check the Panther folder (which is safe to delete, so no guarantees there), etc. but I'm sure this is a problem that people have run into before and (hopefully) solved more elegantly?
(Sidenote: this question has been asked on SO before, but the solution (WMI) is inapplicable for out-of-band checking)
I'm not entirely sure what you mean about out of band checking, so I'm going to ignore that for the moment.
The normal way would be to call GetVersionEx, and look at the wProductType member of the OSVERSIONINFOEX.
A PE image does NOT specify whether the image should work on a client or server. It only specifies the runtime requirements regarding subsystem, dependencies, memory, affinity, etc...
I ended up searching for a number of binaries in the system32 directory that are generally associated with the Server Edition of Windows. It's not very clean, but in practice it works very well.
I have created the necessary manifests for my COM server DLL and a client application to work registration-free in Windows XP. I've tested all kinds of combinations (with and without a registration) and in all cases the client application sees the side-by-side version of the library if the manifests are present, and the registered one if not (or a COM error if there is no registration at all). I've tested on my Windows XP development machine, and given the files (DLL, client EXE and one manifest for each) to co-workers, who've also run everything successfully on their own Windows XP machines. The manifests are external XML files, not embedded resources. So far, so good.
However, when I copy the files to a Windows Server 2003 machine, it doesn't work. I get a silent failure, but an application error in the Application Event Log (see below). If I unregister the DLL and remove the manifests, I get a similar error (silent at the command prompt, but an application error in the event log). Obviously there is some problem finding the registration. I have reproduced this on every Windows Server 2003 machine I can access at our company. According to the Microsoft documentation on side-by-side/registration-free COM, it's supposed to work on Windows XP and later, and Windows Server 2003 and later.
To be clear, the same client runs perfectly on those same Windows Server 2003 machines against a registered (i.e., using regsvr32) version of the same COM DLL, under the same login credentials I'm trying to use for registration-free COM. In other words, there are no intrinsic issues masquerading as registration-free COM problems - this client and server operate fine when the server is registered globally in the registry.
Anybody have any ideas of how to investigate further? I'm not an expert on Windows Server, but is there perhaps some policy setting that would need to be changed to enable this support? If I can locate the necessary change, our tech support/infrastructure people will probably have no probably doing it, but I can't rely on them to research the issue too as they are swamped.
In case it matters (I don't think it should, but you never know) the DLL is written in Delphi 2007, while the client is written in Visual C++.
Event Type: Information
Event Source: Application Error
Event Category: (100)
Event ID: 1004
Date: 5/2/2009
Time: 8:07:45 AM
User: N/A
Computer: ***server name****
Description:
Reporting queued error: faulting application ***program name***.exe, version 0.0.0.0, faulting module ***program name***.exe, version 0.0.0.0, fault address 0x0002ac9e.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
One thing to look for is that whether the exe has an internal manifest. In XP, the exe manifest search order is external then internal. In Server 2003 and later, the order is internal then external.
With a COM server created in Delphi 7, I have seen similar problems if the COM server was unregistered and the client application started under a restricted user account, because Delphi's COM implementation always tried to update the registration information, even when the DLL's RegisterServer function was not explicitly called.
To see whether this is a problem, attempt to run the client application on an account with unrestricted administrative privileges.
MSDN mentions, that under Windows 2003, problems with registration free COM servers should be detailed in a specific section of the system event log:
When troubleshooting registration-free
COM issues, the Event Viewer on
Windows Server 2003 is your friend.
When Windows XP or Windows Server 2003
detects a configuration error it will
typically show an error message box
titled for the application you have
launched and containing the message
"This application has failed to start
because the application configuration
is incorrect. Reinstalling the
application may fix this problem." I
advise that whenever you see this
message you reproduce the problem on
Windows Server 2003, consult the
System Event Log and look for events
from the SideBySide source. The reason
I don't suggest that you look at the
Windows XP Event Log in these cases is
that it will invariably contain a
message such as "Generate Activation
Context failed for [path][application
filename].Manifest. Reference error
message: The operation completed
successfully," which doesn't help
identify the problem.
http://msdn.microsoft.com/en-us/library/ms973913.aspx#rfacomwalk_topic6
Also, if possible, tell us the file names and contents of the manifest files you use.