should escape backslash character in CimXml::unescapeXml()
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
SBLIM |
Unknown
|
Unknown
|
|||
sblim-wbemcli (Ubuntu) |
Fix Released
|
Low
|
Unassigned |
Bug Description
According to the function Cimom::
escaping the quote character, it should also escape the backslash character.
Without escaping backslash, if the string is ended with backslash,
the quoted text output will be ambiguous. The backslash at the end
will be attached to the closing quote, and be interpreted as an escaped
quote character.
According to,
xml: a" --> text output: "a\"" --> interpreted as: a"
then the following will be ambiguous,
xml: a\ --> text output: "a\" --> interpreted as: a" (with trailing garbage characters)
The function then should be fixed like this, (converting "&xxx;" should also be case-insensitive)
string Cimom::
{
- #define REPL(str,chrs) if(strncmp(
+ #define REPL(str,chrs) if(strncasecmp(
{ strcpy (q,(chrs)); \
q+=
p+=strlen(str); }
const char *quotereplace = nq ? "\\\"" : "\"";
+ const char *backslashreplace = nq ? "\\\\" : "\\";
const char *p;
char *q, *buf = (char *) alloca(strlen(m));
for(p=m,q=buf; *p;)
+ // Without escaping backslash, if the string is ended with backslash,
+ // the quoted text output will be ambiguous. The backslash at the end
+ // will be attached to the closing quote, and be interpreted as an escaped
+ // quote character, like this,
+ // * xml: a\ --> text output: "a\" --> incorrectly interpreted as: a"
+ // * xml: a" --> text output: "a\"" --> correctly interpreted as: a"
+ REPL("\
if(*p!='&') { *q++ = *p++; }
else {
Thanks for reporting this bug !
Given the sensitivity of escaping code in general, could you submit it on the SBLIM bugtracker so that the issue gets reviewed and discussed by upstream developers ?
http:// sourceforge. net/tracker/ ?group_ id=128809& atid=712784
If you can't, I'll open it myself, but I probably couldn't defend the proposed patch as well as you would :)
Furthermore, do you see an easy way to reproduce the bug with the stack currently in Ubuntu (how to "inject" a value that ends in \ and that we could use wbemcli to read) ?