In Windows Vista, I am unable to drag/drop files onto my application's window because it is running as a high integrity level process. I need to run it as high, but I also need to be able to accept dropped files from low/medium integrity level processes like Windows Explorer. I believe it is UIPI that is blocking the drag/drop operation. I know that I can use the ChangeWindowMessageFilter function to allow certain Windows messages to bypass UIPI, but I'm not sure which messages to add to allow the drag/drop operation. Is ChangeWindowMessageFilter the right approach to permit this, or is there a better way? Thanks!
Considering the title of this blog entry:
"Why you shouldn’t touch ChangeWindowMessageFilter with a 10-ft pole…",
I guess it is not the best approach ;)
Now, this might seem like a great approach at first - after all, you’ll only use ChangeWindowMessageFilter when you’re sure you can completely validate a received message even if it is from an untrusted source, such that there’s no way something could go wrong, right?
Well, the problem is that even if you do this, you are often opening your program up to attack unintentionally.
Consider for a moment how custom window messages are typically used; virtually all the common controls in existence have “dangerous” messages in the custom class message range (e.g. WM_USER and friends).
Additionally, many programs and third party libraries confuse WM_USER and WM_APP, such that you may have programs communicating cross process via both WM_USER and WM_APP, via “dangerous” messages that are used to make sensitive decisions or include pointer parameters.
In the comments of this blog entry, an alternative approach was discussed, but with pretty much the same conclusion:
I would use RegisterWindowMessage and then allow that via ChangeWindowMessageFilter.
However, be aware that you cannot design a cross-process window message interface that passes pointers or other untrusted values or you are creating a security hole.
For this reason, I would tend to avoid using window at all messages for most cross-process IPC (if possible), as it is typically very difficult to do non-trivial things in a secure fashion using them.
Note: this entry "So, who wants to design a feature today?" illustrates the same problem, and points to the insightful articles of Raymond Chen:
Why aren't console windows themed on Windows XP?
Windows Vista has more extended options on the context menu
which both detail the issue.
This ServerFault question "Why can’t I drag/drop a file for editing in notepad in Windows Server 2008?" also includes some answers, but no quick-win.
See also this article on IE
Related
I am writing an application that will occasionally save data. The Problem is now, when a user logs out of X11 and my application did not yet save the changes, is there a way to detect the logout and write the changes to disk? I tried inmplementing a signal handler for SIGHUP and SIGQUIT without success. Is there a signal that gets emitted or is there a way to lsiten for a logout?
Read ICCCM and EWMH (both are quite large specifications that you should read carefully).
In practice, your X11 application is likely to use some existing GUI toolkit like e.g. Qt or GTK (be sure to use at least GTK3). Then that toolkit should have support related to sessions.
For Qt: look into QSessionManager.
For GTK: see GtkApplication
(if you are stuck with GTK2 - e.g. with lablgtk -, you'll spend months or one or two years of efforts to implement EWMH sessions in your code; porting it to GTK3 -or even to Qt5- should be wiser and might be less work) Since GTK (both GTK2 and GTK3) is free software, you could study the source code (and perhaps be inspired by it, or adapt it to your needs, and/or make an educated guess of the amount of efforts to rewrite it).
Remember that X11 is a network protocol, and the server and the client (and the window manager) could run on different machines (e.g. thru ssh -X). Sending SIGTERM through the network has no sense (and that could explain why EWMH don't mention it).
A workaround might perhaps be to save the state periodically (e.g. every two minutes; then only two minutes of work is lost).
Basile's recommendation of looking at your toolkit's relevant classes (QSessionManager and GtkApplication) is good. I'm thankful he posted that because it helped me find the specific stuff I was looking for.
But if it's as you say, and your toolkit doesn't have built-in session management support, the relevant specification is not EWMH, but rather XSMP. There's a small amount of additional information included in ICCCM that you should also watch out for.
This is far from being a couple years of work. The relevant client-side portions of the session manager protocol should only take a few hours, maybe a couple days if you're unfamiliar with integrating low-level X11 protocols into an existing application stack.
I mean in operating systems or their applications. The only way I can think of is examine binaries for the use of dangerous functions like strcpy(), and then try to exploit those. Though with compiler improvements like Visual Studio's /GS switch this possibility should mostly be a thing of the past. Or am I mistaken?
What other ways do people use to find vulnerabilities? Just load your target in a debugger, then send unexpected input and see what happens? This seems like a long and tedious process.
Could anyone recommend some good books or websites on this subject?
Thanks in advance.
There are two major issues involved with "Client Side Security".
The most common client exploited today is the browser in the form of "Drive By Downloads". Most often memory corruption vulnerabilities are to blame. ActiveX com objects have been a common path on windows systems and AxMan is a good ActiveX fuzzer.
In terms of memory protection systems the /GS is a canary and it isn't the be all end all for stopping buffer overflows. It only aims to protect stack based overflows that are attempting to overwrite the return address and control the EIP. NX Zones and canaries are a good things, but ASLR can be a whole lot better at stopping memory corruption exploits and not all ASLR implementations are made equally secure. Even with all three of these systems you're still going to get hacked. IE 8 Running on Windows 7 had all of this and it was one of the first to be hacked at the pwn2own and here is how they did it. It involved chaining together a Heap Overflow and a Dangling Pointer vulnerability.
The problem with "client side security" is CWE-602: Client-Side Enforcement of Server-Side Security are created when the server side is trusting the client with secret resources (like passwords) or to send report on sensitive information such as the Players Score in a flash game.
The best way to look for client side issues is by looking at the traffic. WireShark is the best for non-browser client/server protocols. However TamperData is by far the best tool you can use for browser based platforms such as Flash and JavaScript. Each case is going to be different, unlike buffer overflows where its easy to see the process crash, client side trust issues are all about context and it takes a skilled human to look at the network traffic to figure out the problem.
Sometimes foolish programmers will hardcode a password into their application. Its trivial to decompile the app to obtain the data. Flash decompiling is very clean, and you'll even get full variable names and code comments. Another option is using a debugger like OllyDBG to try and find the data in memory. IDA-Pro is the best decompiler for C/C++ applications.
Writing Secure Code, 2nd edition, includes a bit about threat modeling and testing, and a lot more.
If i want to develop a registry-like System for Linux, which Windows Registry design failures should i avoid?
Which features would be absolutely necessary?
What are the main concerns (security, ease-of-configuration, ...)?
I think the Windows Registry was not a bad idea, just the implementation didn't fullfill the promises. A common place for configurations including for example apache config, database config or mail server config wouldn't be a bad idea and might improve maintainability, especially if it has options for (protected) remote access.
I once worked on a kernel based solution but stopped because others said that registries are useless (because the windows registry is)... what do you think?
I once worked on a kernel based solution but stopped because others said that registries are useless (because the windows registry is)... what do you think?
A kernel-based registry? Why? Why? A thousand times, why? Might as well ask for a kernel-based musical postcard or inetd for all the point it is putting it in there. If it doesn't need to be in the kernel, it shouldn't be in. There are many other ways to implement a privileged process that don't require deep hackery like that...
If i want to develop a registry-like System for Linux, which Windows Registry design failures should i avoid?
Make sure that applications can change many entries at once in an atomic fashion.
Make sure that there are simple command-line tools to manipulate it.
Make sure that no critical part of the system needs it, so that it's always possible to boot to a point where you can fix things.
Make sure that backup programs back it up correctly!
Don't let chunks of executable data be stored in your registry.
If you must have a single repository, at least use a proper database so you have tools to restore, backup, recover it etc and you can interact with it without having a new set of custom APIs
the first one that come to my mind is somehow you need to avoid orphan registry entries. At the moment when you delete program you are also deleting the configuration files which are under some directory but after having a registry system you need to make sure when a program is deleted its configuration in registry should be deleted as well.
IMHO, the main problems with the windows registry are:
Binary format. This loses you the availability of a huge variety of very useful tools. In a binary format, tools like diff, search, version control etc. have to be specially implemented, rather than use the best of breed which are capable of operating on the common substrate of text. Text also offers the advantage of trivially embedded documentation / comments (also greppable), and easy programatic creation and parsing by external tools. It's also more flexible - sometimes configuration is better expressed with a full turing complete language than trying to shoehorn it into a structure of keys and subkeys.
Monolithic. It's a big advantage to have everything for application X contained in one place. Move to a new computer and want to keep your settings for it? Just copy the file. While this is theoretically possible with the registry, so long as everything is under a single key, in practice it's a non-starter. Settings tend to be diffused in various places, and it is generally difficult to find where. This is usually given as a strength of the registry, but "everything in one place" generally devolves to "Everything put somewhere in one huge place".
Too broad. Its easy to think of it as just a place for user settings, but in fact the registry becomes a dumping ground for everything. 90% of what's there is not designed for users to read or modify, but is in fact a database of the serialised form of various structures used by programs that want to persist information. This includes things like the entire COM registration system, installed apps, etc. Now this is stuff that needs to be stored, but the fact that its mixed in with things like user-configurable settings and stuff you might want to read dramatically lowers its value.
Supposing I was developing a fairly graphically intensive application (C++ or C#, graphics API undecided) for which most of the usage will be by remote users over RDP (either terminal server sessions or remote access to a single-user machine). It's obvious that non-essential "eye-candy" effects and animations should be avoided. My questions are:
What should I be careful to do/avoid doing to make most efficient use of the RDP protocol ? (e.g I have an idea RDP can remote some graphics drawing primitives straight to the client... but is that only for GDI ? Does using double-buffering break such remoting and force a bitmap mode ? Does the client-side bitmap cache "just work" or does it only cache certain things like fonts and icons ?)
Is there any sort of RDP protocol analyser available which will give some insight into what an RDP stream is actually transporting (in particular, bitmaps vs drawing primitives) ? (I can imagine adding some instrumentation to the rdesktop source to do this, but maybe something exists already).
In my experience I'd be careful when it comes to animations - especially fade up/down controls that can seriously kill performance over RDP.
Double-buffering might also cause some problems, however I personally haven't had to do too much in the way of workarounds for this - the article by Raymond Chen explains the possible pitfalls quite well.
Essentially, it's a good idea to check in code whether it's running in a remote sessions (RDP, Citrix, etc). Take a look at: GetSystemMetrics( SM_REMOTESESSION ) - you can then decide at runtime whether to enable or disable certain features.
My idea is that the optimization work made on RDP already cover 90% of the problem you're describing, so I would not worry about optimizing for RDP, you're already removed the eye-candy stuff, you know that the application will be used via RDP so I suppose you'll avoid operations that involves continuous redrawing of form, I believe that sould be enough.
Our application was never designed with RDP in mind, we had the same worries you have when a customer told us that all its client will be used via RDP (Citrix, in that specific case) from remote locations but also if we didn't change a single line of code the customer never called with slowlyness problems due to RDP.
Remember... Premature optimization is evil.
I'm trying to write a tool which lets me inspect the state of a PowerBuilder-based application. What I'm thinking of is something like Spy++ (or, even nicer, 'Snoop' as it exists for .NET applications) which lets me inspect the object tree (and properties of objects) of some PowerBuilder-based GUI.
I did the same for ordinary (MFC-based) applications as well as .NET applications already, but unfortunately I never developed an application in PowerBuilder myself, so I'm generally thinking about two problems at this point:
Is there some API (preferably in Java or C/C++) available which lets one traverse the
tree of visual objects of a PowerBuilder application? I read up a bit on the PowerBuilder Native Interface system, but it seems that this is meant to write PowerBuilder extensions in C/C++ which can then be called from the PowerBuilder script language, right?
If there is some API available - maybe PowerBuilder applications even expose some sort of IPC-enabled API which lets me inspect the state of a PowerBuilder object hierarchy without being within the process of the PowerBuilder application? Maybe there's an automation interface available, or something COM-based - or maybe something else?
Right now, my impression is that probably need to inject a DLL into the process of the PowerBuilder application and then gain access to the running PowerBuilder VM so that I can query it for the object tree. Some sort of IPC mechanism will then let me transport this information out of the PowerBuilder application's process.
Does anybody have some experience with this or can shed some light on whether anybody tried to do this already?
Best regards,
Frerich
First, the easy answer: I think what you're trying to do has been done, sort of. Rex from Enable does what I think you're after, but IIRC from talking with the developers, it depends on code hooks built into the application.
Which leads to the suggestion that I don't think you'll be able to do what I think you're trying to do completely externally from the application. You can grab window handles with WinAPIs and do some basic things with that, but not as much as you want. And getting information about DataWindows with WinAPIs? Forget it.
I believe I've heard of an API like the one you're asking about, but I've never heard of anyone other that automated testing software tool manufacturers getting their hands on it. If this is true (and the quality of this information is along the lines of "heard it in the hallway"), I suspect there might be some application security issues in letting this get out. (I know you'd never want to infect my application, or poke around and find out my secrets. grin)
Even with hooks into the PowerBuilder VM memory space, I'm not aware of being able to get a list of objects in memory without some PowerScript framework hooks (e.g. populating a list on every open and constructor with object handles). Once you've got a window handle, you can easily traverse its control arrays (and its subclasses control arrays) to get a list of objects on the window, but things like handles to NVO instance variables would be problematic.
I admire the idea. I wish I had better news (other than maybe Rex might solve your problem without the headaches of doing it yourself). Now I'm looking forward even more to what eran may release! grin
Good luck,
Terry.
I've just created such a tool, but I cheated a bit. Was actually about to ask the same question myself on the PB newsgroups. My solution is made of two parts:
Spy-like tool - a stand-alone app that like Spy++, i.e. lets you drag a target onto a control, using Windows API functions (though written in PB).
Internal infrastructure for target applications - located at the ancestor of all of the application's windows. Once given a certain (windows) handle, it goes through the Control[] array and looks for the control whose handle matches the given one. If necessary, it also recurses into control-containers such as tabs.
When the user selects a control, the spy tool first looks for its containing window using Windows API. When found, the tool sends a custom message to that window, which is then handled by the app's infrastructure. The control is then located in the PB app, and its details are finally sent back to the spy tool, which presents them to the user.
I suspect the infrastructure part can be replaced with some external thing, as I've seen tools that seem to be able to do that (Visual Expert, QTP). However, I haven't had the time to further investigate, and this solution was relatively easy to develop.
I've got to say, your question comes on a surprising timing. See this recent question of mine. If you're interested in the tool I've created, drop me a comment.