Bug 618622 (CVE-2009-4924) - CVE-2009-4924 python-cjson: XSS attacks due improper sanitization of ['/'] argument
Summary: CVE-2009-4924 python-cjson: XSS attacks due improper sanitization of ['/'] ar...
Alias: CVE-2009-4924
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Felix Schwarz
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2010-07-27 12:04 UTC by Jan Lieskovsky
Modified: 2019-09-29 12:38 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-06-24 07:32:30 UTC

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

Description Jan Lieskovsky 2010-07-27 12:04:00 UTC
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.

  [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 13:20:25 UTC
Is there a proposed fix?

From what I've seen the input '["/"]' should become '["\\/"]'.

Comment 2 Felix Schwarz 2010-07-27 14:36:24 UTC
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 16:11:45 UTC
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 16:17:05 UTC
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 16:24:05 UTC
Security Team: Can you please also file bugs for python-demjson (Fedora + EPEL, all versions)?

Comment 6 Felix Schwarz 2010-07-27 19:34:16 UTC
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-24 03:07:42 UTC
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 06:08:32 UTC
(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 07:32:30 UTC
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.