Out-Of-Boundary Read when parses base64 data about libplist HOT 5 CLOSED

Hi, thanks for pointing this out. I noticed some other issues in the parser, like split data, so I reworked the parsing: 3a55ddd
This also fixes the OOB read and will parse your test case 'correctly' into no data output since it is not properly base64 encoded.

from libplist.

Hi

This has been assigned CVE-2017-5209.

from libplist.

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 3a55ddd, with bbd3379 or with 6a44dfb 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

from libplist.

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

from libplist.

@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.

from libplist.