I have a script that must be launched as root. I need to detect the graphics system and identify it (windows X system, Wayland).
I tried using some environment vars like ${XDG_SESSION_TYPE} or ${WAYLAND_DISPLAY} which are revealing if you are using x11 or wayland, or if you are in a headless system... but, the problem is that the vars are not working from root user. As you know, the graphics environment is usually launched by a normal user and as I said at the beginning of the question, for reasons that I'm not going to explain here, the script needs to be launched as root.
Next screenshot is showing only one common element between users, the XAUTHORITY var...
I could use that but I think that could be a very dirty way to do it. It must be a better way. Any suggestion? Thanks.
The only reliable method is for you to obtain the report, from the environment by a non-root user ID, of the XDG_SESSION_TYPE variable's value.
For X-Windows, XDG_SESSION_TYPE=x11
For Wayland, XDG_SESSION_TYPE=wayland
However, as datenwolf stated, since root is specifically hindered by hard-coded security precautions, even if you customized your root's .bashrc, you won't be able to get the GUI to respond reliably, if at all, depending on the tools and elements you use.
If, on the other hand, you are attempting to build a tool for specific use by high-level security specialists, then you will likely require a customized build of the OS (removing those hard-coded security blocks) to complement those tools. That ... is a huge task, which only those with deep pockets and unlimited resources ... can allow themselves to contemplate ... unless the developers were smart enough to anticipate such a need and have all those code segments "drop-out" during compilation with the appropriate compile-time flag turned on/off. :-)
Related
In Windows software X every link you formulate is automatically converted into a clickable object.
The interesting and security-relevant part here is, that a link like "http://%COMPUTERNAME%.com/" will open the standard browser calling e.g. "http://NR57005-PC.com/", which of course is an information disclosure vulnerability, as all environment variables are converted.
Now my question is, whether this behaviour could lead to more critical issues - e.g. code execution vulnerabilities, which would highly increase the importance of a quick fix.
Do you have any suggestions how to prove, that this this is not only a disclosure issue but a critical vulnerability? Could an attacker inject batch commands by any chance?
I already played around with pipes, ampersands and quotes but so far I didn't find anything interesting.
Thanks in advance,
Patrick
Edit:
To clarify, my approach was the following:
The system must be executing a command like firefox.exe "http://%COMPUTERNAME%.com/", otherwise the system variable would not be converted.
And now, for I know that there is some unfiltered batch call going on, I thought it could be possible to escape the parameter string. For instance, a link like http://google.com/"¬epad&" could have resulted in firefox.exe "http//google.com"¬epad&"", which would have opened the notepad - as a proof of concept that code execution works. Unfortunately this escaping attempt did not work. Therefore I wonder, if there are other tricks to gain shell access or similar.
Your attacker would have to register and control the server NR57005-PC.com. To do so, he would have to have prior information about the hostname(s).
The attack surface presented will depend on the User Agent used to retrieve the link, which will depend on your batch file processing and/or the default browser configured on the system.
Assuming Internet Explorer, your attack surface will be reduced from what you may expect thinking about it as a batch file, because the website will no longer be in the Local Computer zone, but the Internet Zone. Crafty tricks like you're considering won't work.
You're left with using a typical IE vulnerability to gain control. The batch file gains you the opportunity, without depending on a user to visit a malicious website.
I assume you're a pen-tester/auditor and are trying to qualify a finding. I'd recommend
1 - hacking together a demo, but depending on user error to run an executable or similar. You can make the claim a user isn't expecting the browser to give an exe, and thus will be more trusting, even though he should not be.
2 - Recognize the fact it's not a critical vulnerability and move on. An attacker can get the same access/trust more easily through a well-crafted social engineering email.
I have an application that has to support modifying some registry data depending on the kind of 'installation' that is desired. At present, I have no problems hard-coding to either get elevation and do the changes to the entire local machine, but it is far from nice as ideally, I would also like to support per-user installations. I could hardcode that, but then I lose the local-machine stuff. To be precise, the changes in question involve file association changes, COM stuff etc.
How can I properly support both usage scenarios? Currently I use a set of ON/OFF checkboxes for the variety of associations.
Should I change this meaning on, for example, a MachineInstall file existing in my apps directory, and if not assume User install?
Is it an expected/valid/whatever usecase to say that someone might want to do some things for the entire machine, and some things only for the user? (E.g. mixing of the two.)
Or should I change the entire UI, move away from checkboxes and move to some sort of combobox going 'None/User/Local'? Then again, I think this might have some sort of breakage once you involve multiple users and combinations.
To give an indication, I personally expect the application in question to have its uses for everyone on a computer and as such lean towards the Local-Machine as a 'default', if that makes any sort of difference.
I am likely overthinking the matters quite a bit, so any and all input is very much appreciated. :)
P.S.
Now, someone is probably going to say 'do not do all that stuff from your app, do it from the installer instead'. And they probably have a point, but the point is to allow easy changing of these settings from within the application. To top it off, I am not using .MSI install packages because they make working with 32/64-bit specific executables a disaster requiring merge modules, spawning other MSI's depending on the situation, and so forth (I forgot the details last time I dug into it and forgot about the matter). I don't have that knowledge, nor the time to learn all the intricacies of MSI installations, so it is out for as far I am concerned. To boot, my application is perfectly capable of functioning without any of those registry entries being present, and that is by design. In a way, one might compare it to be like Process Explorer from Sysinternals, which does not require an installer, but can be unzipped and take over the task manager etc without a problem if a user wants, or simply run stand-alone.
I'm working hard on making my product work seamlessly on Windows 7. The problem is that there is a small set of global (not user-specific) application settings that all users should be able to change.
On previous versions I used HKLM\Software\__Company__\__Product__ for that purpose. This allowed Power Users and Administrators to modify the Registry Key and everything worked correctly. Now that Windows Vista and Windows 7 have this UAC feature, by default, even an Administrator cannot access the Key for writing without elevation.
A stupid solution would, of course, mean adding requireAdministrator option into the application manifest. But this is really unprofessional since the product itself is extremely far from administration-related tasks. So I need to stay with asInvoker.
Another solution could mean programmatic elevation during moments when write access to the Registry Key is required. Let alone the fact that I don't know how to implement that, it's pretty awkward also. It interferes with normal user experience so much that I would hardly consider it an option.
What I know should be relatively easy to accomplish is adding write access to the specified Registry Key during installation. I created a separate question for that. This also very similar to accessing a shared file for storing the settings.
My feeling is that there must be a way to accomplish what I need, in a way that is secure, straightforward and compatible with all OS'es. Any ideas?
Do you have to have it in the registry? If not, put it into a simple file, writable by everyone. Writing to HKLM requires additional privileges for a very good reason.
I'm new to here (otherwise i would've left a comment) and i'm not a windows guru, but...
imho the premise is wrong:
there's a reason if a non-elevated user cannot modify registry keys or directories read by all users (like Users\Public by default)
i think that allowing any users to modify a small set of global application settings may be disruptive for the experience of the other users that didn't expect their settings to be modified
on the other hand i don't know your use cases...
could you please specify why all users should be able to modify these settings?
and if indeed all users have to be able to do it... why can't you make these settings user-specific?
I have an application which needs to be able to write to Any User/Current host preference files (which requires admin privileges per Preferences Utilities Reference) and also to enable/disable a launchd agent via its plist (writable only by root).
I'm using SFAuthorizationView to require users to authenticate as an admin before altering these values.
I'm trying to decide on the best way to do the actual altering of these values.
The cheap hackish option seems to be to use AuthorizationExecuteWithPrivileges() and mv or defaults, either via BLAuthentication or creating something similar myself. The downside to this is not getting the return value of whatever command line app I'm executing, plus some odd esoteric bugs I've encountered (such as getting a -60008 error in certain situations). This is strongly recommended against by Apple, obviously, but people do seem to do it and have some success with it.
The second most hackish option would seem to be the whole create a helper app with the suid bit set and the --self-repair option as discussed in various places. This seems possible, but like it's probably not much less trouble than the third option.
The third option is to create a fully fledged launchd daemon which will run as root and communicate with my application via a socket. This seems like a bit of overkill to read and write some plist files, but it's also possible I may find other uses for it down the road, and it wont be the only daemon for my application, so it doesn't seem unreasonable to just add another.
I'm thinking about modifying this sample code for my purposes.
My two questions are:
Does the launchd daemon option seem like the best route to go for this, or is there a much easier route I'm missing?
Has anybody else successfully used that code as a basis for something similar, and does anybody see any glaring issues with it I'm missing? I've used it successfully in a test app, but I'd be curious to hear you guys' opinion on it.
launchd is definitely the best and safest way to go: you’ll need an installer package to get your helper into place. Do be sure that your helper does and can do absolutely nothing except edit the files you wish to target.
No experience w/the code, but it’s based off of BetterAuthorizationSample, so that’s a nice start.
There's also the openauth API, which allows you to open files that require root privileges.
I would like to create events for certain resources that are used across various processes and access these events by name. The problem seems to be that the names of the events must be known to all applications referring to them.
Is there maybe a way to get a list of names events in the system?
I am aware that I might use some standard names, but it seems rather inflexible with regard to future extensibility (all application would require a recompile).
I'm afraid, I can't even consider ZwOpenDirectoryObject, because it is described as needing Windows XP or higher, so it is out of question. Thanks for the suggestion though.
I am a little unsure about shared memory, because I haven't tried it so far. Might do some reading in that area I guess. Configuration files and registry are a slight problem, because they do tend to fail with Vista due to access problems. I am a bit afraid, that shared memory will have the same problem.
The idea with ProcessExplorer sounds promising. Does anyone know an API that could be used for listing events for a process? And, does it work without administrative rights?
Thank you for the clarification.
There is not really a master process. It is more of a driver dll that is used from different processes and the events would be used to "lock" resources used by these processes.
I am thinking about setting up a central service that has sufficient access rights even under Vista. It will certainly complicate things, but it might be the only thing left facing the problems with security.
No, there is not any facility to enumerate named events. You could enumerate all objects in the respective object manager directory using ZwOpenDirectoryObject and then filter for events. But this routine is undocumented and therefore should not be used without good reason.
Why not use a separate mechanism to share the event names? You could list them in a configuration file, a registry key or maybe even in shared memory.
Do not mix up the user mode ZwOpenDirectoryObject with the kernel mode ZwOpenDirectoryObject -- the kernel mode API (http://msdn.microsoft.com/en-us/library/ms800966.aspx) indeed seems to available as of XP only, but the user mode version should be available at least since NT 4. Anyway, I would not recommend using ZwOpenDirectoryObject.
Why should configuration files and registry keys fail on Vista? Of course, you have to get the security settings right -- but you would have to do that for your named events as well -- so there should not be a big difference here. Maybe you should tell us some more details about the nature of your processes -- do they all run within the same logon session or do they run as different users even? And is there some master process or who creates the events in the first place?
Frankly, I tend to find the Process Explorer idea to be not a very good one. Despite the fact that you probably will not be able to accomplish that without using undocumented APIs and/or a device driver, I do not think that a process should be spelunking around in the handle table of another process just to find out the names of some kernel objects. And, of course, the same security issues apply again.
ProcessExplorer is able to enumerate all the named events held by some specific process. You could go over the entire process list and do something similar although I have now clue as to what API is used to get the list...