On Oct 28, 2012, at 8:27 AM, Christian Persch <[email protected]> wrote:
>> The standard also notes, "There are important security issues >> associated with encoding conversion, especially with the conversion >> of malformed text." See also <http://www.unicode.org/reports/tr36/>. > > There are no security issues here. A naive PCRE user only wants to know whether a file begins with a particular character sequence, for example, "#!/bin/bash". Not caring whether the file is valid UTF-32 and not having read the documentation very carefully, this programmer uses the flag PCRE_NO_UTF32_CHECK so that the program will run faster (or maybe just having copy-pasted it from somewhere). PCRE says the file matches "#!/bin/bash", so the program executes the file as a bash script, causing a nuclear power plant to explode. The insidious file has already passed inspection by a virus detector, which did not use PCRE_NO_UTF32_CHECK. (I realize that bash scripts aren't generally stored as UTF-32. My intention is only to suggest the general nature of the security risk.) At the very least, if you're unwilling to provide a separate option, change the name to something other than PCRE_NO_UTF32_CHECK. For example, PCRE_DANGER_DANGER_DANGER_INPUT_IS_NOT_UTF32_IGNORE_HIGH_BITS_DO_NOT_USE_THIS_FLAG_UNLESS_YOU_ARE_ABSOLUTELY_SURE_NOBODY_WILL_DIE_AS_A_RESULT. Do any of you happen to be on the mailing list for libcurl? A recent discussion is relevant. The subject line is "The Most Dangerous Code in the World". Due to widespread misunderstanding of the API, many programs using libcurl have made this error: "setting CURLOPT_SSL_VERIFYHOST to TRUE, will result in the SSL connection being insecure against a man-in-the-middle attacker". Sounds harmless, right? Given an option named CURLOPT_SSL_VERIFYHOST, wouldn't TRUE be better than FALSE? In fact it's supposed to be a three valued option, not boolean, and the value "1" is dangerous. Obviously programmers *should* read the documentation more carefully. There's also something to be said for a well-designed API, especially when security issues are involved. Best wishes, Tom 文林 Wenlin Institute, Inc. Software for Learning Chinese E-mail: [email protected] Web: http://www.wenlin.com Telephone: 1-877-4-WENLIN (1-877-493-6546) ☯ -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
