multiple vulnerabilities in input data handling

[QiAnXinCodeSafe]

Hi!
I am a 360 security guard staff member. We found multiple vulnerabilities in Opengrok in our open source code detection project. The details are as follows:
1.XML deserialization vulnerability
The set method in ConfigurationController.java receives the request body in the put request

Finally, the parameter is passed to the decodeObject method and xml is deserialized.

But the attacker will execute the command when passing the following request body.

<?xml version="1.0" encoding="UTF-8"?>
<java version="1.8.0_131" class="java.beans.XMLDecoder">
    <object class="java.lang.ProcessBuilder">
        <array class="java.lang.String" length="1">
            <void index="0">
                <string>calc</string>
            </void>
        </array>
        <void method="start" />
    </object>
</java>

The same problem still exists at line 230 of FileHistoryCache.java

2.Reflective xss
Received two parameters r1 and r2 in the request at line 233 of PageConfig.java.

Finally, after a series of patchwork (but no filtering), output in diff.jsp
E.g:

3.zip_slip
Decompress the zip file in the extractArchive method of FileUtilities.java

Since the zip entry name is not verified, when the zip file maliciously constructed by the attacker is decompressed (the entry name has "../" for path backtracking), the file can be decompressed to any directory, or even overwritten. System Files

[tulinkry]

But the attacker will execute the command when passing the following request body.

Which body?

Thank you for your analysis.

[vladak]

The XML was entered unescaped in the markdown, I fixed it.

[vladak]

Basically, it passes ProcessBuilder with argument. I guess such problems will be eradicated with #2329.

[vladak]

Ideally, this should have been entered as 3 separate issues, we might deal with them as such.

In general, it would be beneficial to have a discussion on what attack vectors are important to us. For example, the XML decoding problem can only happen when it is possible to submit new configuration (this is normally constrained to localhost thanks to LocalhostFilter) which would be a problem on its own so the problem described is not really serious. That said, it pokes another hole in our serialization scheme.