 |
|
|
I can write keys into registry following your code. (I could not before)
I wrote 2 key flv and mp4 into MCI Extensions key in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\MCI Extensions
This helps me to support FLV and MP4 in my application. (write keys and install a codec on the specified PC)
However, after getting elevated right and adding keys, my Windows damaged on Re-start.
This is the error message:
File: \Windows\system32\drivres\intelide.sys
Status: 0xc000000f
Info: Windows failed to load because a critical system driver is missing, or corrupt.
PS: I can add these keys manually and verify that everything works normally.
Could I have any suggestion please?
Thanks,
TuanVo.
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
|
|
|
After adding your code and run it in a Vista-32 machine, the ProcessShellCommand() reports error of "c:\...\runasadmin was not found."
Here is my code. The 1st part is your code; the 2nd part is my original code for Windows XP and below OSs.
What caould be the problem of coding?
Thanks!
BOOL CTrayIconApp::InitInstance()
{
char szMsg[256];
char szCurFolder[1024] = { 0, };
GetModuleFileName(GetModuleHandle(NULL), szCurFolder, 1023);
CString szFullPath = szCurFolder;
szFullPath = szFullPath.Left(szFullPath.ReverseFind('\\'));
g_szProgramFolder = szFullPath;
CCommandLineInfo oCmdLineInfo;
ParseCommandLine(oCmdLineInfo);
g_szCmdLine = oCmdLineInfo.m_strFileName;
if( IsWindowsVista() )
{
if(stricmp(g_szCmdLine, "elevation") == 0)
{
char szCmdLine[1024] = { 0, };
char szCurFileName[1024] = { 0, };
GetModuleFileName(GetModuleHandle(NULL), szCurFileName, 1023);
BOOL bRet = RunAsAdministrator( szCurFileName, (LPSTR)(LPCTSTR)g_szProgramFolder );
if(bRet == TRUE)
{
return FALSE;
}
}
else if(stricmp(g_szCmdLine, "runasadmin") == 0) {
}
else
{
char szCmdLine[1024] = { 0, };
char szCurFileName[1024] = { 0, };
GetModuleFileName(GetModuleHandle(NULL), szCurFileName, 1023);
sprintf(szCmdLine, "\"%s\" elevation", szCurFileName);
WinExec(szCmdLine, SW_SHOW);
return FALSE;
}
}
//
// Below are the original code!!!
//
// Standard initialization
// If you are not using these features and wish to reduce the size
// of your final executable, you should remove from the following
// the specific initialization routines you do not need.
#ifdef _AFXDLL
Enable3dControls(); #else
Enable3dControlsStatic(); #endif
SetRegistryKey(_T("Local AppWizard-Generated Applications"));
LoadStdProfileSettings();
CSingleDocTemplate* pDocTemplate;
pDocTemplate = new CSingleDocTemplate(
IDR_MAINFRAME,
RUNTIME_CLASS(CTrayIconDoc),
RUNTIME_CLASS(CMainFrame), RUNTIME_CLASS(CTrayIconView));
AddDocTemplate(pDocTemplate);
CCommandLineInfo cmdInfo;
ParseCommandLine(cmdInfo);
if (!ProcessShellCommand(cmdInfo))
return FALSE;
char traceTime[200];
initGlobals();
processMutex = OpenMutex(MUTEX_ALL_ACCESS, TRUE, LUCENTTRAYICON_MUTEX) ;
if(!processMutex)
{
processMutex = CreateMutex(0, FALSE, LUCENTTRAYICON_MUTEX) ;
}
else
{
writeTrace("\r\r\n%s:: A instance of TrayIcon is already running, so not starting a new instance\r\r\n", getTime(traceTime));
return FALSE;
}
contactIKEApp();
return TRUE;
}
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
I got the same problem as your.
I found that the only situation that the InitInstance continue is
else if(stricmp(g_szCmdLine, "runasadmin") == 0)
It is after the function RunAsAdministrator was called.
The function RunAsAdministrator set some params and call ShellExecuteExA to get elevated right.
Then I made some change: reset inline params in that situation.
I didn't have chance to test inline call to run my application, since after get elevated and write some keys to registry, my Vista is corrupted as another my post.
However, it helps me to pass your situation.
if(IsWindowsVista()) {
if(stricmp(g_szCmdLine, "elevation") == 0) {
char szCmdLine[1024] = { 0, };
char szCurFileName[1024] = { 0, };
GetModuleFileName(GetModuleHandle(NULL), szCurFileName, 1023);
BOOL bRet =
RunAsAdministrator( szCurFileName, (LPSTR)(LPCTSTR)g_szProgramFolder );
if(bRet == TRUE) {
return FALSE;
}
} else if(stricmp(g_szCmdLine, "runasadmin") == 0) {
__argc=0;
__targv[0]="";
} else {
char szCmdLine[1024] = { 0, };
char szCurFileName[1024] = { 0, };
GetModuleFileName(GetModuleHandle(NULL), szCurFileName, 1023);
sprintf(szCmdLine, "\"%s\" elevation", szCurFileName);
WinExec(szCmdLine, SW_SHOW);
return FALSE;
}
}
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
|
|
|
|
|
|
BOOL IsWindowsVista()
{
OSVERSIONINFO osif;
osif.dwOSVersionInfoSize = sizeof(OSVERSIONINFO);
GetVersionEx(&osif);
if( osif.dwMajorVersion == 6 && osif.dwMinorVersion == 0 )
return TRUE;
return FALSE;
}
|
| Sign In·View Thread·PermaLink | 5.00/5 |
|
|
|
|
|
|
Hi!
I think your code is vulnerable to buffer overflow attacks.
In sprintf(szCmdLine, "\"%s\" elevation", szCurFileName);, when you manage to create a szCurFileName of 1012 characters or more, your sprintf call will overwrite the end of the szCmdLine buffer...
Regards,
mav
--
Black holes are the places where God divided by 0...
|
| Sign In·View Thread·PermaLink | 5.00/5 |
|
|
|
|
|
|
|
|
|
Nope.
MAX_PATH is only the limit for most shell APIs. For most other APIs, that restriction is long gone (the limit for paths on NTFS is 64kB).
|
| Sign In·View Thread·PermaLink | 5.00/5 |
|
|
|
|
|
|
In my experience, When I create nested folder in Windows Explorer, 64kb path length impossible. (even if NTFS format spec has 64kb length of path)
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
"The string returned will use the same format that was specified when the module was loaded. Therefore, the path can be a long or short file name, and can use the prefix "\\?\". For more information, see Naming a File."
(http://msdn.microsoft.com/en-us/library/ms683197(VS.85).aspx[^])
Following the "Naming a File" link you will find this:
"The Windows API has many functions that also have Unicode versions to permit a maximum path length of approximately 32,000 characters composed of components up to 255 characters each in length. To specify that kind of extended length path, use the "\\?\" prefix. For example, "\\?\D:\"."
So yes, you can have 1023 characters in szCurFileName.
And because the szCmdLine has 1024 (same as szCurFileName), but contains szCurFileName + something more, it is a buffer overflow danger.
If the szCmdLine would be 1100 (szCurFileName + "...elevation") it would not be a buffer overflow, but a risk of failure in GetModuleHandle (and not test for that).
And let's remember localization, so if "...elevation" gets translated, 1100 might still not be enough.
|
| Sign In·View Thread·PermaLink | 5.00/5 |
|
|
|
|
|
|
Well, The method which I choose is not proper to all way.
But, Many MSDN example source codes use the Path Buffer with MAX_PATH macro.
MAX_PATH is 256 in Ansi, 512 in Unicode.
And, I think that 1024 is enough to hold path.
The reason why I use 1024 to Command Line Buffer is,
szCmdLine buffer do not use any user inputs.
So, If you want to exploit szCmdLine with Command Line(cmd.exe), you can do that. (Because I do not use User's Input to make szCmdLine.
And I tested in Windows Explorer,
I can not create following long path folder.
'C:\12345678901234567890123456789012345678901234567890\12345678901234567890123456789012345678901234567890\12345678901234567890123456789012345678901234567890\12345678901234567890123456789012345678901234567890\1234567890123456789012345678901234567890\1234567890123456789012345678901234567890'
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
Compile and run this (a quick and dirty example):
#define _UNICODE
#define UNICODE
#include <windows.h>
#include <stdio.h>
#include <tchar.h>
int main( void ) {
TCHAR fullPathName[32000];
TCHAR *folderName = _T("\\Something kind of sort of long(ish)");
_stprintf( fullPathName, _T("\\\\?\\C:" ) );
for( int i = 0; i < 50; i++ ) {
_tcsncat_s( fullPathName, _countof(fullPathName), folderName, _countof(fullPathName) );
CreateDirectory( fullPathName, NULL );
}
return 0;
}
You can then change CreateDirectory(fullPathName, NULL) to RemoveDirectory(fullPathName) and undo the mess, because Explorer is unable to delete it 
|
| Sign In·View Thread·PermaLink | 5.00/5 |
|
|
|
|
|
|
Having to confirm a UAC prompt to login will annoy the user extremely.
That's why Vista blocks elevation prompts for startup programs.
If you need to run an application with administrator rights on logon, you have two choices:
1) Start it using the task scheduler. You can start silently elevated apps on logon this way. WARNING: if your application has any way to start other programs on the user's request (e.g. it's displaying a "Open file" dialog where the user could Right-click>Run on .exe files), that's a security vulnerability!
Better (and suggested by Microsoft):
2) Make your app not require administrator rights. For actions where administrator rights are absolutely required, make the app call into a Windows service running in the background with the necessary permissions. Here, too, you need to take care that your service is secured correctly, but this approach is better because here less code needs to run with admin privileges.
|
| Sign In·View Thread·PermaLink | 3.00/5 |
|
|
|
|
|
|
|
|
|
Another option is to make the app into a service. Vista will enforce UI isolation in that case, as well, which is a bonus.
If you need a front-end then you can have a non-admin client which connects to the service via some kind of RPC.
|
| Sign In·View Thread·PermaLink | 1.75/5 |
|
|
|
|
