snmp_com.txt not protected

From upstream (Guillaume Protet) :

On a pas du tout oublié le sujet. On est justement en train de réfléchir à une solution qui serait relativement sécurisée et qui ne serait pas une usine à gaz à mettre en place. Nous avons plusieurs pistes et il nous reste à vérifier la faisabilité technique.

Une des pistes en cours de réflexion serait de stocker le fichier snmp_com.txt directement en base (et non plus en fichier txt directement accessible en HTTP) et ce serait le moteur OCS qui enverrai le contenu de ce fichier à l'agent dans le XML du PROLOG. On ajouterait une restriction pour que le moteur n'envoie le contenu du fichier uniquement si l'agent communique avec le moteur en HTTPS. Ce serait donc une solution un peu plus sécurisée et relativement rapide à mettre en place. Mais bon, rien n'a été encore tranché là dessus.

(writing in English since this post may be read by others, later)

After a quick verification, the Debian package in version 2.0.2-1 is vulnerable.

Given that the snmp_com.txt file contains community names, which can be read-write, I think this bug can deserve a very important severity.

As a workaround, I'd like to disable the alias line in the Apache configuration (thus, removing access to this file). This will, of course, break any associated feature. Is this OK for the OCS Inventory team ?

Pierre

Hi,

Yes Pierre, we are agree with this solution to wait the final fix. You can comment the "Alias" line in ocsinventory-reports.conf to disable access to snmp_com.txt file. Moreover, you can add a comment to warn user about the deactivtion and security risks if he wants to reactivate the "Alias" line. If you want, you can add a warn in the Readme.Debian file or any other Readme file.

Kind regards,

Guillaume

Added in /etc/httpd/conf.d/ocsinventory-reports.conf for RPM

# Uncomment this Alias to allow SNMP discovery feature
# WARNING this file, with communities definition, will be publicly available
#Alias /snmp /var/lib/ocsinventory-reports/snmp

Hi,

We have just fixed this security issue at server side (web console and engine) and unix agent side:

http://bazaar.launchpad.net/~ocsinventory-core/ocsinventory-ocsreports/stable-2.0/revision/797
http://bazaar.launchpad.net/~ocsinventory-dev/ocsinventory-server/stable-2.0/revision/686
http://bazaar.launchpad.net/~ocsinventory-dev/ocsinventory-unix-agent/stable-2.0/revision/1069

We decide to no longer use snmp_com.txt and SNMP communities data are stored in database. OCS server pass SNMP communities data to agent at PROLOG step. SNMP communities data are sent only if OCS agent communicate with OCS server using HTTPS and if OCS agent DEVICEID is already known in database.

We removes Apache "Alias" configuration from ocsinventory-reports.conf file and we removed SNMP configuration steps in setup.sh script. Moreover, we had a treatment in OCS unix agent postinst.pl script to remove snmp_com.txt file if exists at agent side.

All of this will be integrated in future OCS 2.0.3 release.

Kind regards,

Guillaume

Hi,

Installations script has not fixed the issue when upgrading from 2.0.1 to 2.0.3.
snmp_com.txt still exists and is accesible via http:/ocs/ocsreports/snmp/snmp_com.txt

I've done a manual deletion.

DB aproach is OK, but now we cannot add the same comunity name for snmp v1 an snmp v2c.

Cheers

Hi,

"Alias" directive has been removed in the installation ocsinventory-reports.conf file, so snmp_com.txt should not be accesible using http. Are you sure that ocsinventory-reports.conf (in your Apache configuration) has been upgraded during setup.sh launch ? setup.sh script does not remove snmp_com.txt file because user may have to report commuties names he set in the file into 2.0.3 OCS GUI.

Thanks a lot for the bug report about the same community names. We will fix this ASAP.

Kind regards,

Guillaume

fix commited:
http://bazaar.launchpad.net/~ocsinventory-core/ocsinventory-ocsreports/stable-2.0/revision/804

best regards