Re: Does r32414 Introduce a Security Hole? Do We Already Have One?
On 2009-12-09, rgheck wrote: The problem, as I understand it, is that, under certain circumstances, even a file with extension .jpg can be executed by windows, not by the default viewer. Ask your local spammer for details. AFAIK, the local spammer will attach a file nice-pic.jpg.exe and the mailer will show it helpfully without the administrative extension as nice-pic.jpg but call it as an executable. But you should know that running without admin privileges is not proof against infection. ... More importantly, the question whether a file is executable is not the same as the question what its extension is. That's the whole point. On a DOS (or derived) system, executability is determined on the base of the extension, because It doesn't really have any conception of an executable file. Windows can - see + show the extension .wmf and still treat the file as executable. This is one of the big security holes on Windows: Therefore it is advised to display the extension in the file manager or file selector (this is configurable but by default off). Günter
Re: Does r32414 Introduce a Security Hole? Do We Already Have One?
On 12/09/2009 02:50 AM, Abdelrazak Younes wrote: rgheck wrote: On 12/08/2009 08:57 PM, Uwe Stöhr wrote: If you want to introduce such support for doc, rtf, etc, then you should do it the way we handle dia, xfig, and the like. We should check for a real viewer, such as OpenOffice, Word, or whatever, and if we don't find one then it just defaults to auto. What is the advantage? I don't have Word on my machine so when I execute a doc file, again the default viewer will be opened. It is in this case Wordpad which is available on all Windows system. As I said in my note, your patch leads to problems on every platform except Windows. On Linux, for example, LyX tries to execute file.rtf, which leads to an error message. The use of auto does not lead to such problems, though it leads to absolutely nothing on any platform other than Windows. Are you sure of that? On my KDE system this is properly handled and I believe on Gnome too. Or am I missing something? Well, I tried it here, and got the error message I posted: Systemcall.cpp(111): QProcess %s /tmp/lyx_tmpdir.MT3859/lyx_tmpbuf0/r.rtf did not start! Systemcall.cpp(112): error The process failed to start. Either the invoked program is missing, or you may have insufficient permissions to invoke the program. Error: Cannot view file An error occurred whilst running %s /tmp/lyx_tmpdir.MT3859/lyx_tmpbuf0/r.rtf And the file is there: [rgh...@rghquad ~]$ ls /tmp/lyx_tmpdir.MT3859/lyx_tmpbuf0/ r.aux r.dvi r.log r.rtf r.tex r.tex.dep and can be opened with abiword, or whatever. The correct solution is to detect the viewer and default to auto. But then, when your default viewer changes, LyX will have to run configure again to acknowledge the change; this looks wrong to me. The desktop knows better than LyX what viewer to use. We can simply default to auto, then, if people prefer to do that. But %s is wrong. rh
Re: Does r32414 Introduce a Security Hole? Do We Already Have One?
On 2009-12-09, rgheck wrote: Are you sure of that? On my KDE system this is properly handled and I believe on Gnome too. Or am I missing something? Well, I tried it here, and got the error message I posted: Systemcall.cpp(111): QProcess %s /tmp/lyx_tmpdir.MT3859/lyx_tmpbuf0/r.rtf did not start! Systemcall.cpp(112): error The process failed to start. Either the invoked program is missing, or you may have insufficient permissions to invoke the program. Error: Cannot view file An error occurred whilst running %s /tmp/lyx_tmpdir.MT3859/lyx_tmpbuf0/r.rtf And the file is there: [rgh...@rghquad ~]$ ls /tmp/lyx_tmpdir.MT3859/lyx_tmpbuf0/ r.aux r.dvi r.log r.rtf r.tex r.tex.dep and can be opened with abiword, or whatever. What happens if you click on a *.rtf file in Konqueror? (Maybe you did not set a valid default application?) The correct solution is to detect the viewer and default to auto. But then, when your default viewer changes, LyX will have to run configure again to acknowledge the change; this looks wrong to me. The desktop knows better than LyX what viewer to use. We can simply default to auto, then, if people prefer to do that. But %s is wrong. %s is a placeholder. If a Python file (like configure.py) contains the code auto = Auto str = this is my %s % auto the string str will have the value this is my Auto. If the '%s' is still in the program call, something went wrong. (But the fix must not necessarily be the removal of the placeholder.) Günter
Re: Does r32414 Introduce a Security Hole? Do We Already Have One?
On 2009-12-09, rgheck wrote: > The problem, as I understand it, is that, under certain circumstances, > even a file with extension .jpg can be executed by windows, not by the > "default viewer". Ask your local spammer for details. AFAIK, the local spammer will attach a file "nice-pic.jpg.exe" and the mailer will show it helpfully without the "administrative" extension as "nice-pic.jpg" but call it as an executable. > But you should know that running without admin privileges is not proof > against infection. ... > More importantly, the question whether a file is executable is not the > same as the question what its extension is. That's the whole point. On a DOS (or derived) system, "executability" is determined on the base of the extension, because > It doesn't really have any conception of an executable file. > Windows can - see + show > the extension .wmf and still treat the file as executable. > This is one of the big security holes on Windows: Therefore it is advised to display the extension in the file manager or file selector (this is configurable but by default off). Günter
Re: Does r32414 Introduce a Security Hole? Do We Already Have One?
On 12/09/2009 02:50 AM, Abdelrazak Younes wrote: rgheck wrote: On 12/08/2009 08:57 PM, Uwe Stöhr wrote: > If you want to introduce such support for doc, rtf, etc, then you should do it the way we handle > dia, xfig, and the like. We should check for a "real" viewer, such as OpenOffice, Word, or whatever, and if we don't find one then it just defaults to "auto". What is the advantage? I don't have Word on my machine so when I execute a doc file, again the default viewer will be opened. It is in this case Wordpad which is available on all Windows system. As I said in my note, your patch leads to problems on every platform except Windows. On Linux, for example, LyX tries to execute file.rtf, which leads to an error message. The use of "auto" does not lead to such problems, though it leads to absolutely nothing on any platform other than Windows. Are you sure of that? On my KDE system this is properly handled and I believe on Gnome too. Or am I missing something? Well, I tried it here, and got the error message I posted: Systemcall.cpp(111): QProcess %s "/tmp/lyx_tmpdir.MT3859/lyx_tmpbuf0/r.rtf" did not start! Systemcall.cpp(112): error The process failed to start. Either the invoked program is missing, or you may have insufficient permissions to invoke the program. Error: Cannot view file An error occurred whilst running %s "/tmp/lyx_tmpdir.MT3859/lyx_tmpbuf0/r.rtf" And the file is there: [rgh...@rghquad ~]$ ls /tmp/lyx_tmpdir.MT3859/lyx_tmpbuf0/ r.aux r.dvi r.log r.rtf r.tex r.tex.dep and can be opened with abiword, or whatever. The correct solution is to detect the viewer and default to "auto". But then, when your default viewer changes, LyX will have to run configure again to acknowledge the change; this looks wrong to me. The desktop knows better than LyX what viewer to use. We can simply default to "auto", then, if people prefer to do that. But "%s" is wrong. rh
Re: Does r32414 Introduce a Security Hole? Do We Already Have One?
On 2009-12-09, rgheck wrote: >> Are you sure of that? On my KDE system this is properly handled and I >> believe on Gnome too. Or am I missing something? > Well, I tried it here, and got the error message I posted: > Systemcall.cpp(111): QProcess %s > "/tmp/lyx_tmpdir.MT3859/lyx_tmpbuf0/r.rtf" did not start! > Systemcall.cpp(112): error The process failed to start. Either the > invoked program is missing, or you may have insufficient permissions to > invoke the program. > Error: Cannot view file > > An error occurred whilst running %s > "/tmp/lyx_tmpdir.MT3859/lyx_tmpbuf0/r.rtf" > And the file is there: > [rgh...@rghquad ~]$ ls /tmp/lyx_tmpdir.MT3859/lyx_tmpbuf0/ > r.aux r.dvi r.log r.rtf r.tex r.tex.dep > and can be opened with abiword, or whatever. What happens if you click on a *.rtf file in Konqueror? (Maybe you did not set a valid default application?) >>> The correct solution is to detect the viewer and default to "auto". >> But then, when your default viewer changes, LyX will have to run >> configure again to acknowledge the change; this looks wrong to me. The >> desktop knows better than LyX what viewer to use. > We can simply default to "auto", then, if people prefer to do that. But > "%s" is wrong. "%s" is a placeholder. If a Python file (like configure.py) contains the code auto = "Auto" str = "this is my %s" % auto the string str will have the value "this is my Auto". If the '%s' is still in the program call, something went wrong. (But the fix must not necessarily be the removal of the placeholder.) Günter
Re: Does r32414 Introduce a Security Hole? Do We Already Have One?
rgheck wrote: If you want to introduce such support for doc, rtf, etc, then you should do it the way we handle dia, xfig, and the like. We should check for a real viewer, such as OpenOffice, Word, or whatever, and if we don't find one then it just defaults to auto. The same for WMF and EMF. If you don't like that, then you should at least replace the %s in the lines you changed with auto. As it is now, I think we have a very big security hole. I agree at least with the first part. Jürgen
Re: Does r32414 Introduce a Security Hole? Do We Already Have One?
If you want to introduce such support for doc, rtf, etc, then you should do it the way we handle dia, xfig, and the like. We should check for a real viewer, such as OpenOffice, Word, or whatever, and if we don't find one then it just defaults to auto. What is the advantage? I don't have Word on my machine so when I execute a doc file, again the default viewer will be opened. It is in this case Wordpad which is available on all Windows system. And no, we don't have a security hole. When I execute a file, no matter what type it is, the default program tries to open it. So when you get an infected HTML file, e.g. Firefox will try to open it. If it then infects your system, its a bug in Firefox. If the default viewer is a spam or virus program, it is again your problem because the setting for the default program requires changes in the registry and thus admin permissions. The admin account is only for administration. Users who are logged in as admin to surf in the Internet are already lost. Without Admin permissions you are safe because viruses cannot write to your registry or destroy backup drives. The same for WMF and EMF. If you don't like that, then you should at least replace the %s in the lines you changed with auto. As it is now, I think we have a very big security hole. What's the difference? %s writes auto, doesn't it? WMF and EMF are image formats like JPG and should be treated the same. Actually, I'd like someone to explain to me whether we don't already have one. Suppose I send someone a LyX file together with an executable virus, disguised as a WMF, and then attempt to view or edit it from inside LyX. Can't this cause that file to be executed, thus infecting the user's system? No, this could only infect the system when you have admin permissions and even then only if your PC is already infected. By executing the WMF file you always call the default program for that. So to become infected, the default program needs to have a security hole or is already infected. You scenario is like getting an email with an attachment. You don't become infected by opening a virus email attachment when you are not admin and when it is not an executable. When you execute executables it can only destroy your account that is currently logged in no the whole system. When a virus has the name bla53b.ex.jgp it will not directly be executed but your default image viewer is started. A file is only directly executed when it has the suffix .exe, .bat or .com. LyX itself doesn't include any file - LyX is not dangerous. You can always open a LyX file without being scared. (If you don't trust files sent to you, use a virus scanner but this independent of LyX or any other program.) regards Uwe
Re: Does r32414 Introduce a Security Hole? Do We Already Have One?
On 12/08/2009 08:57 PM, Uwe Stöhr wrote: If you want to introduce such support for doc, rtf, etc, then you should do it the way we handle dia, xfig, and the like. We should check for a real viewer, such as OpenOffice, Word, or whatever, and if we don't find one then it just defaults to auto. What is the advantage? I don't have Word on my machine so when I execute a doc file, again the default viewer will be opened. It is in this case Wordpad which is available on all Windows system. As I said in my note, your patch leads to problems on every platform except Windows. On Linux, for example, LyX tries to execute file.rtf, which leads to an error message. The use of auto does not lead to such problems, though it leads to absolutely nothing on any platform other than Windows. The correct solution is to detect the viewer and default to auto. What's the difference? %s writes auto, doesn't it? WMF and EMF are image formats like JPG and should be treated the same. No. %s on my system writes %s. If you look at configure.py, you will find that the jpeg lines are different from the ones you added. And no, we don't have a security hole. When I execute a file, no matter what type it is, the default program tries to open it. The problem, as I understand it, is that, under certain circumstances, even a file with extension .jpg can be executed by windows, not by the default viewer. Ask your local spammer for details. Or read this: http://msdn.microsoft.com/en-us/magazine/cc164146.aspx. The rest of the discussion has similar issues, which I will not detail. But you should know that running without admin privileges is not proof against infection. (This has been discussed ad nauseam on Linux security lists lately.) A user can get infected (though not the whole system) even if she doesn't have admin permissions. More importantly, the question whether a file is executable is not the same as the question what its extension is. That's the whole point. Windows can see the extension .wmf and still treat the file as executable. This is one of the big security holes on Windows: It doesn't really have any conception of an executable file. Anyway, moving to an auto-based system is necessary, if only to fix the bugs introduced on Linux. What I don't know is whether the auto-based system already introduces vulnerabilities, due to the potential call to rundll. rh
Re: Does r32414 Introduce a Security Hole? Do We Already Have One?
rgheck wrote: On 12/08/2009 08:57 PM, Uwe Stöhr wrote: If you want to introduce such support for doc, rtf, etc, then you should do it the way we handle dia, xfig, and the like. We should check for a real viewer, such as OpenOffice, Word, or whatever, and if we don't find one then it just defaults to auto. What is the advantage? I don't have Word on my machine so when I execute a doc file, again the default viewer will be opened. It is in this case Wordpad which is available on all Windows system. As I said in my note, your patch leads to problems on every platform except Windows. On Linux, for example, LyX tries to execute file.rtf, which leads to an error message. The use of auto does not lead to such problems, though it leads to absolutely nothing on any platform other than Windows. Are you sure of that? On my KDE system this is properly handled and I believe on Gnome too. Or am I missing something? The correct solution is to detect the viewer and default to auto. But then, when your default viewer changes, LyX will have to run configure again to acknowledge the change; this looks wrong to me. The desktop knows better than LyX what viewer to use. [off topic] A user can get infected (though not the whole system) even if she doesn't have admin permissions. I was wondering, you seem to often refer the user as she. Is it because you think of your wife? :-) I though the general English rule was to use the masculine, as in French... Abdel.
Re: Does r32414 Introduce a Security Hole? Do We Already Have One?
rgheck wrote: > If you want to introduce such support for doc, rtf, etc, then you should > do it the way we handle dia, xfig, and the like. We should check for a > "real" viewer, such as OpenOffice, Word, or whatever, and if we don't > find one then it just defaults to "auto". The same for WMF and EMF. If > you don't like that, then you should at least replace the "%s" in the > lines you changed with "auto". As it is now, I think we have a very big > security hole. I agree at least with the first part. Jürgen
Re: Does r32414 Introduce a Security Hole? Do We Already Have One?
> If you want to introduce such support for doc, rtf, etc, then you should do it the way we handle > dia, xfig, and the like. We should check for a "real" viewer, such as OpenOffice, Word, or > whatever, and if we don't find one then it just defaults to "auto". What is the advantage? I don't have Word on my machine so when I execute a doc file, again the default viewer will be opened. It is in this case Wordpad which is available on all Windows system. And no, we don't have a security hole. When I execute a file, no matter what type it is, the default program tries to open it. So when you get an infected HTML file, e.g. Firefox will try to open it. If it then infects your system, its a bug in Firefox. If the default viewer is a spam or virus program, it is again your problem because the setting for the default program requires changes in the registry and thus admin permissions. The admin account is only for administration. Users who are logged in as admin to surf in the Internet are already lost. Without Admin permissions you are safe because viruses cannot write to your registry or destroy backup drives. > The same for WMF and EMF. If you don't like that, then you should at least replace the "%s" in the > lines you changed with "auto". As it is now, I think we have a very big security hole. What's the difference? "%s" writes "auto", doesn't it? WMF and EMF are image formats like JPG and should be treated the same. > Actually, I'd like someone to explain to me whether we don't already have one. Suppose I send > someone a LyX file together with an executable virus, disguised as a WMF, and then attempt to view > or edit it from inside LyX. Can't this cause that file to be executed, thus infecting the user's > system? No, this could only infect the system when you have admin permissions and even then only if your PC is already infected. By executing the WMF file you always call the default program for that. So to become infected, the default program needs to have a security hole or is already infected. You scenario is like getting an email with an attachment. You don't become infected by opening a virus email attachment when you are not admin and when it is not an executable. When you execute executables it can only destroy your account that is currently logged in no the whole system. When a virus has the name "bla53b.ex.jgp" it will not directly be executed but your default image viewer is started. A file is only directly executed when it has the suffix .exe, .bat or .com. LyX itself doesn't include any file - LyX is not dangerous. You can always open a LyX file without being scared. (If you don't trust files sent to you, use a virus scanner but this independent of LyX or any other program.) regards Uwe
Re: Does r32414 Introduce a Security Hole? Do We Already Have One?
On 12/08/2009 08:57 PM, Uwe Stöhr wrote: > If you want to introduce such support for doc, rtf, etc, then you should do it the way we handle > dia, xfig, and the like. We should check for a "real" viewer, such as OpenOffice, Word, or whatever, and if we don't find one then it just defaults to "auto". What is the advantage? I don't have Word on my machine so when I execute a doc file, again the default viewer will be opened. It is in this case Wordpad which is available on all Windows system. As I said in my note, your patch leads to problems on every platform except Windows. On Linux, for example, LyX tries to execute file.rtf, which leads to an error message. The use of "auto" does not lead to such problems, though it leads to absolutely nothing on any platform other than Windows. The correct solution is to detect the viewer and default to "auto". What's the difference? "%s" writes "auto", doesn't it? WMF and EMF are image formats like JPG and should be treated the same. No. "%s" on my system writes "%s". If you look at configure.py, you will find that the jpeg lines are different from the ones you added. And no, we don't have a security hole. When I execute a file, no matter what type it is, the default program tries to open it. The problem, as I understand it, is that, under certain circumstances, even a file with extension .jpg can be executed by windows, not by the "default viewer". Ask your local spammer for details. Or read this: http://msdn.microsoft.com/en-us/magazine/cc164146.aspx. The rest of the discussion has similar issues, which I will not detail. But you should know that running without admin privileges is not proof against infection. (This has been discussed ad nauseam on Linux security lists lately.) A user can get infected (though not the whole system) even if she doesn't have admin permissions. More importantly, the question whether a file is executable is not the same as the question what its extension is. That's the whole point. Windows can see the extension .wmf and still treat the file as executable. This is one of the big security holes on Windows: It doesn't really have any conception of an executable file. Anyway, moving to an "auto"-based system is necessary, if only to fix the bugs introduced on Linux. What I don't know is whether the auto-based system already introduces vulnerabilities, due to the potential call to rundll. rh
Re: Does r32414 Introduce a Security Hole? Do We Already Have One?
rgheck wrote: On 12/08/2009 08:57 PM, Uwe Stöhr wrote: > If you want to introduce such support for doc, rtf, etc, then you should do it the way we handle > dia, xfig, and the like. We should check for a "real" viewer, such as OpenOffice, Word, or whatever, and if we don't find one then it just defaults to "auto". What is the advantage? I don't have Word on my machine so when I execute a doc file, again the default viewer will be opened. It is in this case Wordpad which is available on all Windows system. As I said in my note, your patch leads to problems on every platform except Windows. On Linux, for example, LyX tries to execute file.rtf, which leads to an error message. The use of "auto" does not lead to such problems, though it leads to absolutely nothing on any platform other than Windows. Are you sure of that? On my KDE system this is properly handled and I believe on Gnome too. Or am I missing something? The correct solution is to detect the viewer and default to "auto". But then, when your default viewer changes, LyX will have to run configure again to acknowledge the change; this looks wrong to me. The desktop knows better than LyX what viewer to use. [off topic] A user can get infected (though not the whole system) even if she doesn't have admin permissions. I was wondering, you seem to often refer the user as "she". Is it because you think of your wife? :-) I though the general English rule was to use the masculine, as in French... Abdel.
