Sins of log-entry

[exMSW4319]

Looking through the bug list I note that a lot of the examples include the action log-entry(parameter), where parameter includes a reference to the content causing the specific instance of the bug. CSCuz01651 would be one example in question, but I've seen the same pattern on three or four other write-ups.

It's been previously discussed in the forum that log-entry can cause rather dramatic failures if it is given corrupt information to post to the log. My question is whether the presence of log-entry() is a necessary factor for the bug to appear, and if it was not present in a filter then the bug would not occur and the filter would act as expected.

I can understand that from a purist point of view, the fault is with the prior code handing off garbage to log-entry and that it is far better to fix the fault at that point rather than patch log-entry. It would still be very useful to know if my guess is correct, as we don't use log-entry in our ESA configs so in theory might ignore the vulnerabilities that arise when it is used.

On a side note, many of the bug notes cite the versions of Asyncos where a bug is found and the subsequent versions that fix it. However, looking at the numbering of releases there are sometimes later versions that are also noted for having the bug. Is there any general principle that can be applied to determine what subsequent unmentioned releases of Asyncos will also be free of a particular bug?

[Libin Varghese · Accepted solution]

Hi,

If you are referring to the quoted defect, the log entry is not related to the cause of the vulnerability.

The vulnerability is only due to the type of attachment that is analyzed by the filter, so having the log entry would not really make a difference in this scenario.

I understand there could be scenarios where log entry could create problems, however that is very rare. Mostly TAC recommends adding log entries to filter as it becomes useful in tracking what filter was triggered on the emails.

The Async OS releases mentioned for affected and released versions on defects vary from defect to defect and there has been a few defects with confusing numbering systems. In most scenarios, the expectation is that the fixed release would include the fixes in releases ahead in numbering as well. However, that is not always the case.

Thank You!

Libin Varghese

[exMSW4319]

Thanks for the clarification, Libin.

It looks as if there's a couple of hefty upgrades in my future...