Followup to: <[EMAIL PROTECTED]>
By author: Henry Spencer <[EMAIL PROTECTED]>
In newsgroup: linux.utf8
> Um, no, I think you've missed my point. The user of a decoder is *not*
> going to get bitten by these security holes, because he's
> *decoding*.
... and thus losing any verification done by any other layer of
software.
> The act of decoding transforms the input into a form where these
> holes do not exist. The potential for security holes comes when you
> attempt to use the raw input, *without* decoding it. It is the
> *non-decoding* users who are vulnerable.
Great. Now you have a datastream with may contain, say, embedded '/'
in filenames, or null characters. If you then convert them back to
UTF-8 you now have a string referring to a potentially completely
different file than you started with. If this isn't a security hole,
I don't know what is.
> This being so, decoding users -- who are not vulnerable -- may balk at
> having their programs misbehave on inputs which do not threaten them anyway.
This is complete nonsense. See above.
> > Implicit aliases are very dangerous.
>
> I agree, but the problem is to protect the non-decoding users, and doing
> substitutions in decoders may not be the best way to do that.
--
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/lists/
