In handler.rb, the first argument to the syslog.err calls needs to contain a "%s" argument, otherwise another exception will result. This construct in the "report" method io.write "REASON=#{exception.format.first}\0" should guard against embedded NUL characters, to prevent injection of other keywords in the submitted message.
Thank you for reporting. Would you mind to share reproducers and what is the impact?
This is based on source code review only. Impact is misleading or missing crash data.
1) I tried to log string with NULL character and yes, the part of the string behind NULL is missing, but what would be the expected output? You suggest to use "%s" but using syslog.err "%s" % s nor syslog.err "%s", s has no effect. The part behind NULL is lost. Also note that since the error handler is expected to handle errors, which are caused by problems writing into the socket, I can hardly imagine how this could cause any issues. 2) As for the "io.write" case, the only possible abuse, I can think of might come from Exception#message. That means it should be probably handled earlier at lib/abrt/exception.rb#L9, but what would you suggest? I can imagine that self.message.gsub(/\0/, "\n") could help there, or I can cut off everything behind NULL (or raise exception ;)). But on the other side, I hope that ABRT is robust enough to handle such malformed reports. But anyway, unless there is clear what we actually want to prevent/achieve, I hesitate to change anything.
(In reply to Vít Ondruch from comment #4) > 1) I tried to log string with NULL character and yes, the part of the string > behind NULL is missing, but what would be the expected output? You suggest > to use "%s" but using > > syslog.err "%s" % s > > nor > > syslog.err "%s", s > > has no effect. The part behind NULL is lost. Sorry, what i meant is that this is needed in case the message contains a "%". > 2) As for the "io.write" case, the only possible abuse, I can think of might > come from Exception#message. That means it should be probably handled > earlier at lib/abrt/exception.rb#L9, but what would you suggest? I can > imagine that self.message.gsub(/\0/, "\n") could help there, or I can cut > off everything behind NULL (or raise exception ;)). You could strip all NUL characters, replacing them with nothing at all.
(In reply to Florian Weimer from comment #5) > Sorry, what i meant is that this is needed in case the message contains a > "%". Ah, now I see: > syslog.err "% " ArgumentError: invalid format character - % from (pry):48:in `err' Ok, so I can go with: > syslog.err "%s", "% " => <#Syslog: opened=true, ident="abrt", options=3, facility=8, mask=255> Still the question remains, is this real world problem?
This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux.
(In reply to Vít Ondruch from comment #6) > Still the question remains, is this real world problem? I do think this is worth fixing, but doing so in Fedora is good enough.
Fixed upstream: https://github.com/voxik/abrt-ruby/commit/5e0b1d10c512ebfbddd7790e46ea0782d83a0171 https://github.com/voxik/abrt-ruby/commit/c430c5bb37506e7778cf53e9ed19d024b58c6c3b
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
rubygem-abrt-0.1.1-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-14748
rubygem-abrt-0.1.1-1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update rubygem-abrt'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-14748
rubygem-abrt-0.1.1-1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.