|Issue 773||TrendMicro: A remote debugger stub is listening in default install|
|Starred by 4 users||Project Member Reported by email@example.com, Mar 22 2016||Back to list|
Mar 22 2016,
Issue 767 has been merged into this issue.
Mar 22 2016,
Response from Trend Micro. Hi Tavis, This is Roy from Trend Micro Consumer Support. We will be your point of contact for the reported bug found on Trend Micro Security Program. We are currently checking the POC with our Product Team and will provide you with timely updates regarding this. Best Regards, Roy
Mar 22 2016,
Update from Trend Micro, I'm not sure what mitigation they're planning, but I volunteered to look at the build. Hello Tavis, I just wanted to share an update on the Chromium Remote Debugger stub issue you reported to us on Friday afternoon. Our product development team was able to reproduce and isolate the issue and is currently working on resolving it as quickly and completely as possible. As of right now, we have a 2-staged approach for fully addressing the issue: 1. Within the next couple of days, we are planning to push an update that mitigates and provides a measure of protection against this in the short term. However, since this is not a full and permanent solution, we do have some additional steps we need to take before we consider it resolved. 2. We believe the root cause of the issue partly involves a 3rd party module. Our permanent solution involves opening up the source code of the module and not only to fix this issue completely, but to also thoroughly test for any similar issues and address those accordingly. Due to the complexity involved with this module, we are estimating about a 3-4 week timeframe for a complete and final solution. Before we make the final solution publicly available, we would like to ask for your assistance in helping us to test and validate it to ensure it has fully resolved the issue. If everything looks good at that point and we are able to push this to our customers, we look forward to working with you on a coordinated public disclosure of your findings. Again, we thank you for bringing this to our attention promptly and thank you in advance for your time and efforts in helping us to resolve these issues fully and completely. Please feel free to let us know if you have any concerns or questions on this, and we will definitely keep you in the loop on any new updates. Best Regards,
Mar 22 2016,
I asked what they meant by "short term": Hello Tavis, Our development team was able to repackage the installer for new installations last night. We are looking to proactively push an update to all existing users starting on 3/24 to ensure they get the short-term solution as quickly as possible while we work on the final solution. As mentioned before, although we believe this update provides protection, we won’t consider the issue completely fixed until the next step as previously mentioned to you, so we are definitely not ready for public disclosure at this time. Again we definitely appreciate all your feedback, and look forward to continuing to work with you to get this addressed completely.
Mar 22 2016,
I'll see what the patch does before deciding if we'll agree to delay disclosure. I think we would only agree to that if it's not possible to determine the vulnerability from what the patch does. Frankly, the issue is already ridiculously easy to discover and exploit though.
Mar 23 2016,
Reply from Trend Micro: ================ Thanks for your note and we can definitely understand where you are coming from. The main background of this issue is that because it involves a 3rd party binary and it’s not our native code, our development team estimates they will need extra time to crack open the source code to disable the debug port, rebuild it and reintegrate into our product package. The short-term fix comprises of us modifying the Password Manager service to force itself to occupy a port upon launch that would than prevent the debug port from binding. We’ve also built in the logic that if for some reason the service were to stop or be killed, it would go through the same occupy/prevent sequence again to guard against this. While we believe this will prevent the exploit you were able to submit to us, it is our preference to actually completely disable the debug port from the source code level – which because of the 3rd party source is taking us a little longer. We do have builds available of the short-term fix that we can provide for validation. What we would request is that if you and your team can validate that the short-term fix is sufficient enough in your view to protect against the potential exploit while we still move forward on the permanent solution – we can work with you on the coordinated disclosure. However, if the short-term fix does still have some issues, we would like the opportunity to try and address this before disclosure as to not to potentially risk our customers’ safety with an insufficient patch. 32-bit: [...] 64-bit: [...] Again, our foremost concern is that we do not expose our customers to an undue risk with an earlier disclosure if the short-term solution does not sufficiently provide protection against a potential exploit. This is why your validation is extremely important if we proceed. Please let us know if this action plan works for you and if you have any additional questions or concerns. We look forward to your feedback. ================ Well, that did explain their concern. This sounds like a very fragile fix, and I understand why they want to do it properly and why they can't modify a third party binary overnight. I am concerned it will be obvious from anyone looking at the patch what the problem was, I'll discuss this with my colleagues.
Mar 24 2016,
I looked at the patch using BinDiff and had some concerns about the quality of the fix, and identified some edge-cases where it would fail. I sent some notes to TM about it. TM Reply: ------------- Our current thought is instead of diverting precious RD time and resources to rebuild the short-term patch that we feel will still have some issues as you’ve pointed out, we move forward with at least silently pushing the existing short-term for partial protection (we feel it’s better than nothing) and put our full effort into getting the full solution complete as soon as possible. However, if we do this, we would like to earnestly request your assistance in trying to obtain an exception to your disclosure policy as previously mentioned, since we are in agreement that a spotlight on the short-term solution via an early public disclosure would make it obvious what the issue is, thereby potentially raising the risk level to affected users before we are able to fully resolve it. At the end of the day our biggest concern is the safety and protection of our users. We have placed our plans to push the short-term update on hold pending your feedback, and look forward to hearing back from you. ----------------- I replied "I think you're saying that that handling the corner cases I'm worried about are not worth delaying the update - and I suppose I agree.", but it's very obvious what the patch is doing, and as per industry standards, we think it would be best to make users aware about the flaw and the need to patch. The cases we can think of where it fails requires a pretty unlikely sequence of events while PwmSvc.exe is being restarted or a colluding local attacker, which really lowers the severity. TM Reply: --------------------- [...] And the situations in which the patch would fail require is definitely not trivial and would be require a specific sequence of events or access to come to fruition – thus making it a much less severe vulnerability. Is that correct? [...] --------------------- I think we're in agreement the temporary patch will be released shortly, and a slightly censored advisory will be released, as I agreed not to discuss the limitations of the patch. TM plan to release a more complete and permanent patch within a few weeks.
Mar 27 2016,
TM: ------------- I’ve reconfirmed with our team that they will restart the process to prepare the short-term fix for push deployment via our ActiveUpdate process. Factoring in the Easter holiday weekend, deployment QA, the need to address some specific Service Provider builds that need to also have this added, and the staggered percentage rollout I mentioned before – we anticipate the patch being widely available by Friday, April 1st, and are hoping that we could ask you to time any disclosure around that date to ensure that customers would have access to the patch appropriately and not have any risk exposure. -------------- This bug is so easy to discover and exploit, and they already have the build they want to deploy, I asked why they can't accelerate the roll-out. I understand they need to test this on Mac & PC, and have other products I'm not aware of (probably branded products they make for banks, OEMs and so on) - but still. TM Reply: ------------------ We are definitely on the same page that the severity and priority of this issue is absolutely critical which is why we went back to our development stakeholders to see how we can accelerate this even further. After re-reviewing everything that needs to happen to get this patch out as soon as possible globally, and pulling in additional resources over the weekend, it looks like we are going to be able to shave off a couple of days off the original date – and now targeting to have this deployed out to affected users by Wednesday (3/30) instead of the previous date of Friday (4/1). ------------------- So it looks like the patch will be available on Wednesday.
Mar 30 2016,
TM ------------------------------ We just wanted to circle back with you to confirm we did get the patch deployed today (3/30) as we mentioned to you over the weekend. We are also continuing full speed ahead on the long-term version and hope to get that out as quickly as possible as well. Thank you again so much for working with us on this, and we are also continuing work on the other Titanium vulnerability you submitted to us as well -------------------------------- Removing view restrictions.
Mar 31 2016,
So is there a zero day on Titanium? Not sure if you wanted to make this public. From comment #12: Thank you again so much for working with us on this, and we are also continuing work on the other Titanium vulnerability you submitted to us as well
Mar 31 2016,
Thanks, but we don't consider the existence of vulnerabilities to be confidential - only the vulnerability details themselves.
|► Sign in to add a comment|