[RFC] Security and Features in KPDF

Malte S. Stretz msquadrat.nospamplease-hi6Y0CQ0nG0 at public.gmane.org
Mon Jan 3 00:29:39 GMT 2005

On Monday 03 January 2005 01:08 CET Ingo Klöcker wrote:
> On Monday 03 January 2005 00:19, Tobias Koenig wrote:
> > some times ago there was an implementation for KPDF which allows to
> > execute an application which is specified in the PDF document.
> >
> > The implementation was criticized by some developers because of
> > security concerns.
> >
> > IMHO the feature is really nice. When you use acroread/kpdf as
> > presentation program for a talk, you can/could directly start the
> > application you talk about without closing the presentation program
> > first (which looks quite unprofessional).
> >
> > The main concerns are, that some bad guy could create a PDF file with
> > the command 'rm -Rf /' inside I guess. This problems can be solved by
> > always asking the user whether he wants to execute this application
> > and showing him the full command that will be executed.
> >
> > This is really a save solution. When the user still clicks on 'Ok'
> > and the virus/wurm is executed... well, that's the users problem.
> Yeah, right. Since when do users read dialogs? I can assure you that
> enough people are already trained to click on each [OK] button they see
> without even think about reading the text of the dialog. Especially, if
> they've already seen the same dialog in the same situation (here,
> clicking on a link in a PDF) a hundred times. Do you really believe
> that the users will still read the text of the dialog when it comes up
> the 101st time?

Maybe if KDE used the same feature as Mozilla for Really Dangerous 
Actions(tm):  The dialog contains a countdown which will keep the OK button 
disabled.  And the focus is on the Cancel button (so just hittin return 
won't harm either).

> > But
> > that's the same case as when the user clicks on an unknown email
> > attachment. Do we forbid email attachments for this reason?
> That's nonsense. Clicking on an unknown email attachment in KMail does
> never result in 'rm -Rf /' or similarly dangerous commands being
> executed. [...]

What about HTML?  Ok, maybe there's no rm -rf possible, but why isn't in 
PDFs everything allowed which is in HTML?  Ok, maybe not erverything (like 
JavaScript which is AFAIK possible with Acrobat 6 though), but at least 
every link?

That way one (aka Tobias) could put a script or whatever at a well know 
place and put a file-URL to that place into his PDF file.  A click 
executes, after a dialog of course.  Ok, that would still give the user 
enough rope to hang himself, but hey, how would that be less secure than 
the attached HTML file?  (Have you noted that the focus is on the "Execute" 
button btw?)

Just my 2 cents, if it sounds sick, the reason might be that I'm sick 
currently (hope I didn't get the chickenpox at the 21c3).


[SGT] Simon G. Tatham: "How to Report Bugs Effectively"
[ESR] Eric S. Raymond: "How To Ask Questions The Smart Way"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050103/8fd3f216/attachment.html>

More information about the kde-core-devel mailing list