Hi, I am still a little lost of this masking feature. I know why we need it in compile. But why we need it in exec? I know if you read a character, which is > 0x10ffff, and read its UCD value (e.g matching to a unicode property), you get a crash regardless of masking. But that is ok, since the input must be a valid UTF stream in UTF mode (performance VS safety - we prefer the first). I know there are other engines, which prefers the second, but you have to pay its price.
Honestly, I would never use PCRE in security critical environment. The code is in a really good shape, but it is too complex. In WebKit, we use sandboxing, and we doesn't care WebKit itself is safe or not (the second is more likely, it is just too big). Tom, you could use that approach as well. So my question is, do we really need masking in exec? Regards, Zoltan Philip Hazel <p...@hermes.cam.ac.uk> írta: >On Sun, 28 Oct 2012, Tom Bishop, Wenlin Institute wrote:> > > 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. > > With respect, I think this is a bit drastic.> > Anybody writing a program where the consequences of failure are so > catastrophic *should* care whether the file is valid UTF, should read > the documentation, and shouldn't just copy-paste.> > I know people are stupid. Are they really *that* stupid? Should we not > implement PCRE_NO_UTFx_CHECK at all? Using it incorrectly can cause> crashes and problems in all modes. I am happy to beef up the warnings in> the docs.> > > 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? > > The word "insecure" doesn't sound harmless to me! > > > 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. > > It is regretful that the C language does not have proper boolean > values/variables, but instead subverts ints. > > Philip> > -- > Philip Hazel> > -- > ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev > -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
