Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 618622 - (CVE-2009-4924) CVE-2009-4924 python-cjson: XSS attacks due improper sanitization of ['/'] argument
CVE-2009-4924 python-cjson: XSS attacks due improper sanitization of ['/'] ar...
Status: CLOSED NOTABUG
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Felix Schwarz
public=20091202,reported=20100702,sou...
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-27 08:04 EDT by Jan Lieskovsky
Modified: 2016-03-04 07:56 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-06-24 03:32:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
proposed fix (1.07 KB, patch)
2010-07-27 12:17 EDT, Felix Schwarz
no flags Details | Diff
revised version of fix (1.05 KB, patch)
2010-07-27 15:34 EDT, Felix Schwarz
no flags Details | Diff

  None (edit)
Description Jan Lieskovsky 2010-07-27 08:04:00 EDT
Common Vulnerabilities and Exposures assigned an identifier CVE-2009-4924 to
the following vulnerability:

Dan Pascu python-cjson 1.0.5 does not properly handle a ['/'] argument
to cjson.encode, which makes it easier for remote attackers to conduct
certain cross-site scripting (XSS) attacks involving Firefox and the
end tag of a SCRIPT element.

References:
  [1] http://pypi.python.org/pypi/python-cjson/
  [2] http://t3.dotgnu.info/blog/insecurity/quotes-dont-help.html
Comment 1 Felix Schwarz 2010-07-27 09:20:25 EDT
Is there a proposed fix?

From what I've seen the input '["/"]' should become '["\\/"]'.
Comment 2 Felix Schwarz 2010-07-27 10:36:24 EDT
Currently investigating the issue, actually Python's json library behaves like cjson in that respect. I'm trying to clarify if this is actually a security issue at all. 

The second link you posted does not work for me currently (server does not answer) so I need some time for verification.
Comment 3 Felix Schwarz 2010-07-27 12:11:45 EDT
Some explanation from John Millikin (author of jsonlib) why this input needs to be escaped:
> If "/" is not escaped, then user-sourced fields are vulnerable to
> injection, because browser error-handling heuristics may parse the
> string "</script>" as markup:

>  loadUsers({"users": [{"name": "Joe Smith</script><script
>  type='text/javascript'>alert('injected!')</script><script
>  type='text/javascript'>", "age": 40}]})

Actually I found that also simplejson 2.1 is vulnerable (while 1.7 in EL4 is not) as well as Python 2.x and Python 3.x.

Security team: Can you please file issues for Python 2+3 (all supported Fedora versions + EL6) + python-simplejson (all Fedora, EL5, EL6).
Comment 4 Felix Schwarz 2010-07-27 12:17:05 EDT
Created attachment 434739 [details]
proposed fix

I created a small patch which I believe fixes the issue. Can someone review this?
Comment 5 Felix Schwarz 2010-07-27 12:24:05 EDT
Security Team: Can you please also file bugs for python-demjson (Fedora + EPEL, all versions)?
Comment 6 Felix Schwarz 2010-07-27 15:34:16 EDT
Created attachment 434814 [details]
revised version of fix

Actually the current url of the blog post referenced as [2] is http://notmysock.org/blog/insecurity/quotes-dont-help

With the help of John Millikin (author of jsonlib) I was able to produce a revised patch which fixes the issue.

There is some work left to be done which you might consider a bug but to me it was more important to fix the security bug than doing upstream's work:
The parser was not modified, which means that 
   cjson.decode(cjson.encode("/")) != "/"
The issue existed previously as
   cjson.decode(r"\/") != "/"
however now with correct escaping it is more likely that user's trigger the issue.

I looked into implementing a correct fix and it turned out that someone tried that before (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534709). However that patch was turned down because upstream (which was alive back then) said the "correct fix is to modify the parser to take into account the solidus, so that it can all be done in 1 stage with only 1 buffer."

As python-cjson uses Python's PyString_DecodeEscape function for its parser needs, this means one actually needs to write a new escape-aware parser from scratch.

Therefore I'm for leaving the parsing issue and just release a package with the correct escape fix.
Comment 7 Deron Meranda 2014-06-23 23:07:42 EDT
Technically this is not a bug in cjson (or any other JSON package), but rather a potential bug in other applications which may incorrectly embed or parse embedded JSON.

That being said, if you are to make a downstream patch to make it "HTML-safe", it should probably escape all special HTML/XML characters or sequences that could otherwise result in improper parsing.  Also you need to do so according to the JSON (RFC 7159) grammar, which has a more restricted set of escape sequences than does JavaScript.

You should escape:

/ (U+002F)  =>  \/
< (U+003C)  =>  \u003c
> (U+003E)  =>  \u003e
& (U+0026)  =>  \u0026

Also note that escaping ">" is additionally useful to prevent accidental recognition of the XML CDATA delimiter "]]>".
Comment 8 Deron Meranda 2014-06-24 02:08:32 EDT
(In reply to Felix Schwarz from comment #5)
> Security Team: Can you please also file bugs for python-demjson (Fedora +
> EPEL, all versions)?

python-demjson version 2.2.1 now supports an 'html_safe' option which will insure the generated JSON is safe to embed inside HTML.  The equivalent option for it's included 'jsonlint' command is --html-safe.

See Fedora update task, bug# 1100731
Upstream info: http://deron.meranda.us/python/demjson/
Comment 9 Felix Schwarz 2014-06-24 03:32:30 EDT
Deron, you're right - I came to the same conclusion some time ago. Also python-cjson is retired/orphaned for F20 / EPEL6 so I guess we can close this bug.

Note You need to log in before you can comment on or make changes to this bug.