Merge lp:~doctormo/inkscape/fix166371 into lp:~inkscape.dev/inkscape/trunk
Status: | Merged |
---|---|
Merged at revision: | 12510 |
Proposed branch: | lp:~doctormo/inkscape/fix166371 |
Merge into: | lp:~inkscape.dev/inkscape/trunk |
Diff against target: |
128 lines (+59/-16) 1 file modified
src/xml/repr-io.cpp (+59/-16) |
To merge this branch: | bzr merge lp:~doctormo/inkscape/fix166371 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Inkscape Developers | Pending | ||
Review via email: mp+185064@code.launchpad.net |
Description of the change
This is a fix for our critical blocker regarding Adobe vs Hackers in bug 166371. I should explain some things:
The security vuln occurs when SYSTEM calls load data from the hard drive, using replacements with entities causes it to open a huge security hole where private data can be stolen. This can be closed by stopping the parsing of ENTITIES. libxml2's response to the vulnerability was very poor IMO, simply killing an entire feature of their library without sufficient protection when it's switched back on.
But Adobe files REQUIRE ENTITY replacements for their namespace attributes.
What this fix does, is firstly attempt a normal open, so most files will not be slowed down by the filtering. If it fails in the specific way Adobe files fail... which is to cause a valid document with no namespace i.e. ns:svg instead of svg:svg then it attempts to reload the document, this time it switches on NOENT /and/ the same switch strips SYSTEM out of the read buffer before it gets to the parser. Thus even an adobe file can't be used to steal data and there is no vuln.
The alternative fix, is to switch NOENT back off and manually replace each of the Adobe namespace entities, but this is longer winded and needs updating in any ways files might differ. Please advise as the code is similar and doesn't require much change between them.