Version: 1.0.1 (using KDE KDE 3.2.1) Installed from: Debian testing/unstable Packages OS: Linux KPF is unable to serve files with more than one dot in a row in its name. Example: file "04....mp3" produces: 403 Forbidden Rename it to "04.mp3" and it works.
This is because kpf refuses anything that looks like this type of exploit attempt: ../../../../etc/passwd. kpf should probably only refuse anything containing '../', not '..', but I'll have to think about it a little more before making a decision, in case that's too simplistic.
You call this a "security" seriously?! ;) Uhh.... You should not refuse anything unless it breaks the chroot. For example, this is fully valid non-hax0r path and should be handled w/o any harm "http://kpf-host:8001/dir/../file....mp3" All you need is chroot. Or, at least you shall validate real path the URI translates into and refuse if it tries to go outside given root dir. But not do anything like you described.
On Friday 26 March 2004 20:43, Marcin Orlowski wrote: > You call this a "security" seriously?! ;) Uhh.... You should not > refuse anything unless it breaks the chroot. For example, this is fully > valid non-hax0r path and should be handled w/o any harm > "http://kpf-host:8001/dir/../file....mp3" All you need is chroot. KPF can't chroot. It's a kicker panel applet and runs unprivileged. Even if it had privilege to call chroot, doing so would chroot kicker, which would be quite silly. > Or, at least you shall validate real path the URI translates into > and refuse if it tries to go outside given root dir. KPF does that as well. > But not do anything like you described. I don't think there's anything wrong with doing 'pre-' validation of the given path, as it avoids having to perform the more expensive operation of checking the _actual_ path, which occurs later. The bug is that KPF is one character too strict, so breaks legitimate requests like your example. Rik
> The bug is that KPF is one character too strict, so breaks legitimate > requests like your example. Well it seems people does not serve tricky files with KPF (otherwise you would mark my report as DUP), so I think checking agains "../" would suffice, even it will break legal "http://kpf-host:8001/dir/../file....mp3". I can live with that though. Please consider changign return code KPF throws back to the browser in case of found "violation". 403 is misleading in such case and I'd rather suggest 412 maybe? Or 406?
Any progress on this bug ? It seems that it has been several years since it was reported and is still present in KDE 3.5.6. It concerns files containing "~" as well as ".." in their names. This is not purely theoretical. It is a serious problem. For example, lots of Debian and Ubuntu packages containing "~" in their file names. It actually happened to me and I was forced to install Apache. I have reported it here in Ubuntu: https://bugs.launchpad.net/ubuntu/+source/kdenetwork/+bug/113483 I also e-mailed the author without response. What happens if he has stopped maintaining this software ?
Tzvetan, sorry for not responding - I read your email and forgot to reply. I have stopped maintaining kpf because I don't have time. If you are able to create a patch, please do so and submit it to the kde-devel list - hopefully someone will be able to test and apply it. Thanks, Rik
I will give it a try in the next several weeks. Once I have figured out the basics of KDE development (libraries, etc), I expect not to have a problem coming up with a working patch, especially since it isn't in the GUI part. It would be a shame to leave such a useful tool stagnate, so I will do my best. regards, Tzvetan
All reports about kpf has been closed because is no more developed and mantained. Thanks all anyway for contributing with bug reports.