Pickle security and remote logging
Hello, I need to send logging module output over the network. The module has everything to make this happen, except security. SocketHandler and DatagramHandler examples are using pickle module that is said to be insecure. SocketHandler and DatagramHandler docs should at least contain a warning about danger of exposing unpickling interfaces to insecure networks. pickle documentation mentions that it is possible to control what gets unpickled, but there is any no example or security analysis if the proposed solution will be secure. Is there any way to implement secure network logging? I do not care about data encryption - I just do not want my server exploited by malformed data. -- anatoly t.
anatoly techtonik <techtonik <at> gmail.com> writes:
insecure. SocketHandler and DatagramHandler docs should at least contain a warning about danger of exposing unpickling interfaces to insecure networks.
I've updated the documentation of SocketHandler.makePickle to mention security concerns, and that the method can be overridden to use a more secure implementation (e.g. HMAC-signed pickles). Regards, Vinay Sajip
On Tue, Jun 29, 2010 at 6:15 PM, Vinay Sajip <vinay_sajip@yahoo.co.uk> wrote:
I've updated the documentation of SocketHandler.makePickle to mention security concerns, and that the method can be overridden to use a more secure implementation (e.g. HMAC-signed pickles).
Thanks. But I doubt HMAC complication helps to protect logging server. If shared key is compromised -server becomes vulnerable. I would prefer approach when no code execution is possible. Some alternative serialization way for transmitting log data structures over network. Protocol buffers first come in mind, but they seem to be an overkill, and stdlib doesn't include any implementation. -- anatoly t.
On Tue, Jun 29, 2010 at 4:22 PM, anatoly techtonik <techtonik@gmail.com> wrote:
On Tue, Jun 29, 2010 at 6:15 PM, Vinay Sajip <vinay_sajip@yahoo.co.uk> wrote:
I've updated the documentation of SocketHandler.makePickle to mention security concerns, and that the method can be overridden to use a more secure implementation (e.g. HMAC-signed pickles).
Thanks. But I doubt HMAC complication helps to protect logging server. If shared key is compromised -server becomes vulnerable. I would prefer approach when no code execution is possible. Some alternative serialization way for transmitting log data structures over network. Protocol buffers first come in mind, but they seem to be an overkill, and stdlib doesn't include any implementation.
You could use marshal by default. It does not execute code when unmarshalling. A limitation is that it only supports built-in types like list, dict, string etc. but that might be just fine for logging data. Another option would be JSON. (Or XML, if you want bulky. :-) As for protocol buffers, assuming its absence (so far :-) from the stdlib is the only objection, how hard would it be to make the logging package "prepared" so that if one *did* have protocol buffers installed, it would be a one-line config setting to use them? -- --Guido van Rossum (python.org/~guido)
Guido van Rossum <guido <at> python.org> writes:
As for protocol buffers, assuming its absence (so far from the stdlib is the only objection, how hard would it be to make the logging package "prepared" so that if one *did* have protocol buffers installed, it would be a one-line config setting to use them?
I envisage that if protocol buffers were available, and if support for them in logging was to be added, this could be done via an optional keyword arg to the SocketHandler which sets a handler attribute, which would then be used in makePickle to make the required serialized form. @anatoly: The documentation just mentions HMAC as an example; the levels of paranoia to be applied are different for different people, different times and different situations ;-) I assume that someone reading the docs could readily see that they could substitute "sign the pickle" with some alternative strategy in makePickle. You could implement marshal, protocol buffers etc. right now just by overriding SocketHandler.makePickle in your custom class. An alternative strategy would be to provide an optional serializer=None callable in the SocketHandler constructor. If specified, then makePickle would call this serializer with the LogRecord instance as the only argument, and use the return value as the serialized form, instead of calling pickle.dumps. Regards, Vinay Sajip
participants (3)
-
anatoly techtonik -
Guido van Rossum -
Vinay Sajip