Closed geekwish closed 7 years ago
Hi, thanks for pointing this out. I noticed some other issues in the parser, like split data, so I reworked the parsing: https://github.com/libimobiledevice/libplist/commit/3a55ddd3c4c11ce75a86afbefd085d8d397ff957 This also fixes the OOB read and will parse your test case 'correctly' into no data output since it is not properly base64 encoded.
Hi
This has been assigned CVE-2017-5209.
Hi,
I created asdf.plist as @geekwish said:
emilio@tatooine$ cat asdf.plist <data trn="1.0" 0//EN" "http.DTDs/ProWerwwk.arsion="1.0">>
Now if I parse it with plist 1.12, I get:
emilio@tatooine$ /opt/libplist/bin/plistutil -i asdf.plist Entity: line 1: parser error : error parsing attribute name <data trn="1.0" 0//EN" ^ Entity: line 1: parser error : attributes construct error <data trn="1.0" 0//EN" ^ Entity: line 1: parser error : Couldn't find end of Start Tag data line 1 <data trn="1.0" 0//EN" ^ Entity: line 1: parser error : Extra content at the end of the document <data trn="1.0" 0//EN" ^ ERROR
With git commit 3a55ddd3c4, with bbd33793d or with 6a44dfb72 I get instead:
emilio@tatooine$ /opt/libplist/bin/plistutil -i asdf.plist bplist00@ emilio@tatooine$
(with some unicode garbage after the "@")
Is that expected? That doesn't look right to me
Ping? I'd like to issue a security update downstream with a fix for this issue, but since I'm unable to reproduce it, I can't be sure if the fix is working on the backport.
Perhaps I have a bad test case? Can you add the correct one as an attachment?
Thanks
@epozuelo I am not sure what you are doing there, but if I try to convert the file
$ cat asdf.plist
<data trn="1.0" 0//EN"
"http.DTDs/ProWerwwk.arsion="1.0">>
(without enclosing <plist></plist>
tags)
the output since commit 3a55ddd is the following:
$ PLIST_XML_DEBUG=1 plistutil -i asdf.plist
libplist[xmlparser] ERROR: EOF while looking for closing tag
libplist[xmlparser] ERROR: Could not parse text content for 'data' node
ERROR: Failed to convert input file.
so the aforementioned issue is already fixed and the parsing fails. No idea why you actually seem to get binary plist output though.
And if it parse
one possible patch