I am reverse engineering a binary that is supposed to run as root and performs simple checks on users passwords by reading /etc/shadow. I am able to leak some shadow file entries due to public r/w permissions set on the IPC mechanism.
How would this kind of vulnerability be categorised and described in an official report ?
Generally speaking you want to split your categorisation into weakness and impact. In this case the weakness is that a process with elevated privileges (root in this case) exposes an IPC mechanism with excessively permissive access control. The impact is that you can access data that you shouldn't be able to as an unprivileged user.
It is easy to get this backwards. For example, you could look at the impact and decide that the weakness is an information disclosure. This is incorrect as the issue does not arise because of an information disclosure. Rather, the issue arises because of excessively permissive access control, and results in information disclosure.
[In addition to the accepted answer] Since you mentioned an official report, It would be a good idea to classify the impact of this vulnerability into two categories: Technical Impact and Business Impact.
The technical impact would help people who would want to develop a defense against the issue. The business impact would be for the consumption of the executives and decision makers as it should help them prioritize the fix or a compensating control. In case you are presenting this report to an audience containing execs, having a business impact section helps to convey the right message.
Some of the points to consider while evaluating the business impact are:
