[RFC] Security and Features in KPDF

Malte S. Stretz msquadrat.nospamplease-hi6Y0CQ0nG0 at public.gmane.org
Mon Jan 3 20:05:48 GMT 2005

On Monday 03 January 2005 19:53 CET Oswald Buddenhagen wrote:
> On Mon, Jan 03, 2005 at 07:43:59PM +0100, Ingo Klöcker wrote:
> > On Monday 03 January 2005 01:23, Oswald Buddenhagen wrote:
> > > On Mon, Jan 03, 2005 at 01:08:51AM +0100, Ingo Klöcker wrote:
> > > > you can be sure that several distributions will make "kpdf
> > > > --script %u" the default for PDF "because it's so convenient".
> > >
> > > and this is our problem, right? uhm, well ...
> >
> > Even if it's not our problem who do you think will get the complaints?
> and? do you care? RESOLVED -> INVALID.
> > There's a difference between a security hole and a consciously added
> > security problem.
> yes, but the effect is the same. by adding a feature you risk security
> holes. whether a hole is techical or just human stupidity is irrelevant.
> the only safe way is not adding the feature at all. that's not the way
> to user satisfaction.

Actually, with all those security holes in xpdf (and thus KPDF) last year, 
I'd be very reluctant to add any "execute embedded code" feature.  It's 
just too easily exploitet -- wait for the next xpdf hole, write a PDF file 
which contains a whole lot of nice script code and just smash the stack to 
jump there.  How convenient, next door's script kiddie doesn't even have 
inject some of this head hurtung binary hex crap, all he needs to know is 
bash.  Yeehah, ye're 0wned.

Seriously, as I already mentioned, if KHTML allows to execute local commands 
via URLs, I don't see a reason not to allow this (including relative links) 
in PDF.  And in PostScript, LaTeX, MS Word, whatever else might allow URLs.  
In the end they are all just different formats to represent documents.  So 
treat them all the same but make damn sure that you've got a good 
protection against abusement.


[SGT] Simon G. Tatham: "How to Report Bugs Effectively"
[ESR] Eric S. Raymond: "How To Ask Questions The Smart Way"

More information about the kde-core-devel mailing list