This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vinay.sajip
Recipients Arfrever, ncoghlan, vinay.sajip
Date 2012-07-26.18:07:35
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1343326057.83.0.364715829328.issue15452@psf.upfronthosting.co.za>
In-reply-to
Content
Having reflected on this further, ISTM that limiting the scope of evaluation is not the correct answer. For example, a malicious user could still send a bogus configuration which, for example, just turns the verbosity of all loggers off, or configures a huge number of bogus loggers. This would certainly be allowed even by a limited-evaluation scheme if a user legitimately wanted to do so; but if a malicious user sends the exact same “legal” configuration, it is still a security exploit because the consequences may be undesirable to the victim.

But how is the listener to know whether or not the configuration is coming from a legitimate source (a client process controlled by the same user who is running the process which uses listen())  or a malicious user (a client process controlled by some other user)? The simplest answer would appear to be a shared secret: When listen() is called, it is passed a text passphrase, which is also known to legitimate clients. When handling a configuration request via the socket, the configuration is checked to see if it contains the passphrase. If it does, the request is processed; otherwise, it is ignored.

In the fileConfig() input data, the passphrase could be provided via a passphrase=secret entry in the [default] section. In the dictConfig() input data, the passphrase could be provided against the passphrase key in the dict which is passed to dictConfig(). The checking would be done in the request handler code before calling fileConfig() or dictConfig(). If the passphrase argument to the listen() call is None (the default, preserving the current behaviour) no passphrase checking would be done.
History
Date User Action Args
2012-07-26 18:07:38vinay.sajipsetrecipients: + vinay.sajip, ncoghlan, Arfrever
2012-07-26 18:07:37vinay.sajipsetmessageid: <1343326057.83.0.364715829328.issue15452@psf.upfronthosting.co.za>
2012-07-26 18:07:37vinay.sajiplinkissue15452 messages
2012-07-26 18:07:36vinay.sajipcreate