From: Herman B. <he...@bl...> - 2004-11-20 20:07:05
|
----- Original Message ----- From: "Nathan Walp" <fac...@fa...> To: "Herman Bloggs" <he...@bl...> Cc: <gai...@li...> Sent: Saturday, November 20, 2004 2:11 PM Subject: Re: [Gaim-devel] Re: [Gaim-commits] CVS: gaim/src gtkblist.c,1.197,1.198 gtknotify.c,1.69,1.70 gtkutils.c,1.96,1.97 notify.c,1.10,1.11 notify.h,1.14,1.15 Herman Bloggs wrote: >> My use of the word 'trusted' did not refer to the connection but rather the >> 'source' or creator of the URI. After googling around, it seems that there >> are vulnerabilities on other platforms as well.. depending on the browser >> that is used to execute the file URI.. Here is one such discussion about it: >> >> http://cert.uni-stuttgart.de/archive/bugtraq/2001/07/msg00333.html >> >If you cannot trust the connection, you cannot trust the source, because >you don't really know the source. Otherwise mallory can sit between you >and the other end, and have your "trusted" source "send" you whatever it >wants. So then in this case trusted would be FALSE. > >> We are going from a situation of 100% trust to one that questions the source >> of a URI.. so I don't understand why you think this results in "trusting WAY >> more URIs" than the previous situation. > >If I read the diff correctly, we're going from a situation of 0% trust >to one of 100% trust, since you changed the old behavior of: > >if(URI is http/https/ftp/mailto) > >to > >if(URI is "trusted" or URI is http/https/ftp/mailto) > The 100% trust was at the core level.. The Windows filtering of URIs was a temporary fix, and does nothing for other platforms. >And changed just about every call to gaim_notify_uri (other than >something in trepia, and the case where a user clicks on a link in an >IM) to pass TRUE for trusted. This means that prior versions of gaim >would properly handle the case where a malicious jabber server (for >example) sent the registration URI as "deltree /y c:\*.*" (or whatever >it is that makes things go boom), and now it will call ShellExecute() >with that same thing. > >Every call to gaim_notify_uri save 1 falls into one of two categories: >1. Internal URL that passed the http/https/ftp/mailto filter, can set >FALSE but it won't make any difference either way >2. URL we get from the network, which we have no business passing >through unfiltered, so we should be passing FALSE, even though we're not >in several cases > >The only time we should ever pass TRUE is for a URI we constructed >ourselves that is not assured to be an HTTP URI. The only place we do >this is in MSN, which doesn't itself pass the trusted paramater, but >lets gaim_notify_emails do it for it. So now we have the situation >where gaim_notify_emails is assuming that whoever calls it is calling it >with safe URIs. MSN calls it with a safe URI, but from what I can tell >oscar and yahoo do not follow suit. > >So now I think I can screw with a win32 build in the following ways >where I couldn't before: >1. malformed jabber registration packet >2. malformed oscar new-mail packet >3. malformed yahoo new-mail packet >4. malformed oscar change-passord something > >If I'm dead wrong, I'd like to know where I misread the code. If I'm >not, I think we need to find another solution. If you're correct in the cases you mentined then trust should be FALSE. In the case of the trust case for Windows, we are still not doing the right thing.. If local files are passed to gaim_notify_uri, they should follow the URI file scheme which is currently not the case for the MSN email signon. Then, if using ShellExecute, we need to further filter to make sure an accpeted URI scheme is used whether trusted or not.. So that part is not finished. What you havn't addressed is the case of file URIs or new-scheme URIs being passed to gaim_notify_uri at the core level, for all platfroms. With the code as it was, we did not distinguish between a URI that came over the network (assuming it was a URI.. as we did not check), and one that came from within gaim. Perhaps the alternative I suggested earlier would be more preferable, where selected URI schemes are accepted by gaim_notify_uri (excluding the file scheme) and where gaim_notify_uri is used only for URIs that come over that network. Then gaim_notify_internal_uri (which allows the file scheme) would be used for URIs that are generated from within gaim such as the MSN email signon. There is really no difference, however, other than the splitting the job into two functions.. the same decsions still need to be made by those using these functions. > > > >> The reason I made the change in the core api, was so that decisions about >> how to deal with this extra information (trust of a URI source), could be >> taken by those implementing the processing of URIs on the various >> platforms.. After all they can ignore this information if they wish to. >> >> - Herman |