CVE-2020-29362 & CVE-2020-29363

DevOps security
#1

Bonjour,

Although some hosts are impacted by this CVE, I don’t think they are actually vulnerable.

An issue was discovered in p11-kit 0.21.1 through 0.23.21. A heap-based buffer over-read has been discovered in the RPC protocol used by thep11-kit server/remote commands and the client library. When the remote entity supplies a byte array through a serialized PKCS#11 function call, the receiving entity may allow the reading of up to 4 bytes of memory past the heap allocation.

Comments are welcome!

1 Like
#2

Bonjour,

Ca pourrait être inquiétant vu la nature de l’application mais apparement on ne peut lire que 4 octets en dehors de l’espace alloué, donc potentiellement il faudrait forcer l’écriture de données sensibles dans cet espace et ne pouvoir en lire que 4 octet à la fois. Il y as assez peu d’informations et je ne trouve pas de POC donc, dans la limite de ce que je sais, ca n’as pas l’air très inquiétant…

PS: On peut lire les données contigues en plus des 4 octets donc en fait selon comment le programme alloue la mémoire ça pourrait être plus problématique.

1 Like
#3

There now is a mail notification sent every 6 hours about this CVE. I suppose the Debian security team is working on it and it is just a matter of waiting. It would probably be good to make it so recently disclosed CVE can be silenced for a few days/weeks. But I’m not sure there is a way to do that.

1 Like
#4

They answered to my issue telling me it was planned but they had no date for when it would be deployed, since they took several years answering pull requests I think we have time before it is implemented.

#5

This is good news, meaning your thinking on the matter goes in the right direction. It’s not too much of a problem to use a workaround (adding to local rules), as long as there is hope for a real fix, even if it is in a long time.

I will manually add an exception:

$ cat /var/ossec/etc/rules/local_rules.xml
<!-- Local rules -->
<group name="vulnerability-detector">
...
  <rule id="100011" level="0">                                                                                               
    <if_sid>23506</if_sid>
    <field name="vulnerability.cve">CVE-2020-29362|CVE-2020-29363</field>                                                                   
    <description>https://forum.enough.community/t/686</description>                                           
  </rule>
</group>
$ systemctl restart wazuh-manager

This will keep it quiet until enough runs on the infrastructure and reverts the change. When that happens, if the fix has not been released yet, the same exception will have to be manually added again because messages will be sent again. This will be ok unless it takes too long. But in any case there is no risk to forget about this CVE which is, IMHO, the most important quality of this workaround.

Maybe there is a simpler way to handle this use case?

#6

For the record both CVE were fixed and all machines upgraded.