Canon WiFi vulnerabilities - new firmwares will be released

Started by Sapporo, August 07, 2019, 07:10:21 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Sapporo

An international team of security researchers has drawn our attention to a vulnerability related to communications via the Picture Transfer Protocol (PTP), which is used by Canon digital cameras, as well as a vulnerability related to firmware updates.
(CVE-ID:CVE-2019-5994, CVE-2019-5995, CVE-2019-5998, CVE-2019-5999, CVE-2019-6000, CVE-2019-6001)

Due to these vulnerabilities, the potential exists for third-party attack on the camera if the camera is connected to a PC or mobile device that has been hijacked through an unsecured network.

At this point, there have been no confirmed cases of these vulnerabilities being exploited to cause harm, but in order to ensure that our customers can use our products securely, we would like to inform you of the following workarounds for this issue.

    Ensure the suitability of security-related settings of the devices connected to the camera, such as the PC, mobile device, and router being used.
    Do not connect the camera to a PC or mobile device that is being used in an unsecure network, such as in a free Wi-Fi environment.
    Do not connect the camera to a PC or mobile device that is potentially exposed to virus infections.
    Disable the camera's network functions when they are not being used.
    Download the official firmware from Canon's website when performing a camera firmware update.

Models Affected

These vulnerabilities affect the EOS-series digital SLR and mirrorless cameras PowerShot SX740 HS, PowerShot SX70 HS, PowerShot G5X Mark II.


https://www.usa.canon.com/internet/portal/us/home/support/product-advisories/detail/the-vulnerability-in-canon-digital-cameras

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6001

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6000

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5999

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5998

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5994

kitor

QuoteEOS R firmware version 1.3.0 and earlier

Hmm, I'm sure the latest public one is 1.2.0 ::)

Anyway, seems like a possible entrypoint to enable bootflag on R.
Too many Canon cameras.
If you have a dead R, RP, 250D mainboard (e.g. after camera repair) and want to donate for experiments, I'll cover shipping costs.

Sapporo


walter_schulz

Any word about the fix affecting the key currently used by ML devs?

EDIT: And why aren't other D5 cams like 650D, 100D, M/M2, 700D *not* vulnerable (according to Canon)?

chris_overseas

Quote from: walter_schulz on August 11, 2019, 10:08:11 PM
Any word about the fix affecting the key currently used by ML devs?

I doubt this is a concern, the vulnerabilities found aren't related to the firmware encryption. I also wonder if it's even possible for Canon to update the AES key with a firmware update.

Quote from: walter_schulz on August 11, 2019, 10:08:11 PM
EDIT: And why aren't other D5 cams like 650D, 100D, M/M2, 700D *not* vulnerable (according to Canon)?

"Even though our camera model doesn't support Bluetooth, some Bluetooth-related commands were apparently left behind, and are still accessible to attackers. In this case, we found a classic Stack-Based Buffer Overflow" - maybe those cameras don't have the Bluetooth code in their firmware, or different versions of it that aren't vulnerable?
EOS R5 1.1.0 | Canon 16-35mm f4.0L | Tamron SP 24-70mm f/2.8 Di VC USD G2 | Canon 70-200mm f2.8L IS II | Canon 100-400mm f4.5-5.6L II | Canon 800mm f5.6L | Canon 100mm f2.8L macro | Sigma 14mm f/1.8 DG HSM Art | Yongnuo YN600EX-RT II

Sapporo

Quote from: chris_overseas on August 12, 2019, 09:35:01 AM
I doubt this is a concern, the vulnerabilities found aren't related to the firmware encryption. I also wonder if it's even possible for Canon to update the AES key with a firmware update.

"Even though our camera model doesn't support Bluetooth, some Bluetooth-related commands were apparently left behind, and are still accessible to attackers. In this case, we found a classic Stack-Based Buffer Overflow" - maybe those cameras don't have the Bluetooth code in their firmware, or different versions of it that aren't vulnerable?
They are vulnerable according to CVE. 7D together with WFT-E5 isn't on the other hand mentioned.

chris_overseas

This quote is an interesting one from a security PoV, and potentially problematic for ML going forwards:

"There is a PTP command for remote firmware update, which requires zero user interaction. This means that even if all of the implementation vulnerabilities are patched, an attacker can still infect the camera using a malicious firmware update file"

Of course this approach requires the secret AES key, but the attackers have demonstrated this isn't too difficult to obtain. The specific vulnerability covering this is https://nvd.nist.gov/vuln/detail/CVE-2019-5995. It's interesting they describe it as a "missing authorization" problem. That seems to imply the fix involves the addition of an authorization step (to the PTP negotiation or call?) rather than an overhaul of the encryption itself. If so then ML shouldn't be impacted, but I think that still remains to be seen.

As a side note, I need to take my 5DIV in for a service this week due to a sticky scroll-wheel. They normally update to the latest firmware as part of the service, so I'll find out soon enough where things stand on the 5DIV at least.

[edit: https://www.magiclantern.fm/forum/index.php?topic=17360.msg219613#msg219613 implies the patch isn't a problem as far as ML is concerned]
EOS R5 1.1.0 | Canon 16-35mm f4.0L | Tamron SP 24-70mm f/2.8 Di VC USD G2 | Canon 70-200mm f2.8L IS II | Canon 100-400mm f4.5-5.6L II | Canon 800mm f5.6L | Canon 100mm f2.8L macro | Sigma 14mm f/1.8 DG HSM Art | Yongnuo YN600EX-RT II

kitor

I asked Eyal Itkin directly and from what he told me - they tested this only on 80D. List of affected cameras was prepared by Canon themselves.
Too many Canon cameras.
If you have a dead R, RP, 250D mainboard (e.g. after camera repair) and want to donate for experiments, I'll cover shipping costs.

names_are_hard

I was at the conference where this was released, but I didn't attend that talk, sadly (I'll be able to watch the video in a few weeks).

The Scout debugger sounds like it could be useful, but I don't think there's enough info yet for us to use it:
Quote
We can't say that switching to the WiFi interface worked out of the box, but eventually we had a Python script that was able to send the same exploit script, this time over the air. Unfortunately, our script broke.
[...]
Armed with our new vulnerability, we finished our exploit and successfully loaded Scout on the camera.

So, they had to do quite a lot of work to install a network debugger via an exploit.  Code for Scout is available, but the installation code for Canon isn't.  We can happily run arbitrary code direct from SD so it's easier for us in theory, but we have no expertise with their debugger (which requires working wifi comms to a custom client).  Being able to do live inspection would be pretty cool so it might be worth the effort to get it working - I would suggest doing this on a cam with a nice stable ML implementation first.

71m363nd3r

The whole process is interesting from my point of view.

a1ex

These vulnerabilities are about anyone being able to execute custom code remotely (e.g. via the Wi-Fi network), without user interaction, or even without user knowledge. The same is true via USB, but that's arguably less of a concern, as you'd have to physically connect the cable.

Quote from: chris_overseas on August 12, 2019, 11:48:49 AM
[edit: https://www.magiclantern.fm/forum/index.php?topic=17360.msg219613#msg219613 implies the patch isn't a problem as far as ML is concerned]

Right. At least on 80D 1.0.3, the portable ROM dumper worked out of the box without any changes (same old FIR file).

Quote from: chris_overseas on August 12, 2019, 09:35:01 AM
I also wonder if it's even possible for Canon to update the AES key with a firmware update.

They can, by reflashing the bootloader, but that would disable the ability to run previous firmware updates (i.e. it would no longer be possible to downgrade). They did not touch the bootloader in the 80D 1.0.3 update.

Quote from: chris_overseas on August 12, 2019, 11:48:49 AM
[...] potentially problematic for ML going forwards [...]

The impact, in my opinion, is that it's now harder for Canon to silently ignore us, as we were mentioned quite a few times in the writeup.

Not sure how to proceed from here, though.

nikfreak

a1ex do you expect negative impact for us? Mentioning ML several times in the article hopefully won't harm future research on upcoming cameras but my gut feeling says that Canon hopefully won't change anything relevant on existing cameras.

Did anyone from CP contact you?

@Canon if you read this: How about sponsoring ML, please  ;D.
[size=8pt]70D.112 & 100D.101[/size]

names_are_hard

I am not alex, but I am a software security guy, and have worked with bounty programs, bug reports etc extensively.  I can only guess, but I have seen these kinds of reports from both sides and know some patterns in responses.

There's not much technical risk for Canon here, but there is some PR risk.  Tech-wise, their dev teams will hopefully get more time / money to improve quality in networking code, as well as removing ability to do a silent firmware update without physical access (this last part especially!  Why does PTP allow this?).  This would have no impact on ML.  They may choose to make firmware updates generally more difficult / authenticated to perform, but I would guess not; there's not much value for an attacker in firmware update attacks that require physical access to typically consumer, typically non-networked devices that don't hold business critical data.  And if you do make updating firmware harder, useful updates are harder as well as higher risk (which means higher testing cost) that you accidentally break cams in the field - which customers really hate.  The dev team product manager probably just wants to fix the specific bugs, maybe harden the code in that area, and then get back to the massive backlog of known bugs, feature requests, new versions for new hardware, etc.

*If* management judge the PR hit is sufficiently bad that they need to have a big visible response to reassure customers, then it's more likely ML and other after-market players will see problems.  I don't think this is likely in this case.  It rarely happens with non-networked consumer devices, most buyers simply don't know or don't care, so companies aren't motivated to make changes (which is honestly reasonable; it means buyers get the things they want, cheaper).  With stuff like phones, routers, PCs, there's more media coverage, and the impact is bad enough if it does get exploited, that consumers get scared and management drives bigger changes.

TL;DR - low risk ML gets shut out, but we can only guess.

Luther

Quote from: names_are_hard on August 21, 2019, 06:18:32 PM
And if you do make updating firmware harder, useful updates are harder as well as higher risk (which means higher testing cost)

Not necessarily. Canon can just add TPM 2.0 on newer cameras. This would prevent update by others (including ML), because only they would have the key. TPM doesn't make it any difficult for them and solves the problem with little effort.

names_are_hard

I hadn't considered TPM (TEE / PSP on Arm?) and don't know if Canon ship the right HW feature.  I don't think it matters though, they could simply use asymmetric crypto instead of AES.  Regardless, any change in this area would be months of work for a dev team, plus more for testing, which is my point - there's significant dev cost that they won't want to pay.  There's also real risk that a big change to firmware updating bricks customer cameras.  They might choose to pay the costs if the PR risk is judged worth it.  But, probably cheaper just to fix the bugs, maybe look for similar bugs, and move on.  Protects the customers the same.

Luther

Quote from: names_are_hard on August 25, 2019, 06:41:32 AM
I hadn't considered TPM (TEE / PSP on Arm?)

TrustZone could work too.

Quote
and don't know if Canon ship the right HW feature.

Not current cameras. I meant the next generation of cameras.

Quote
they could simply use asymmetric crypto instead of AES.

Do you mean homomorphic? This would imply adding wifi to every camera, including the cheaper ones...

Quote
Regardless, any change in this area would be months of work for a dev team

I don't know about that. TPM is not that complicated. There's companies with know-how on this, and Canon could simply contract to do the work...

Quote
bricks customer cameras.

Firmware update wouldn't be any difficult or more harmful. They could make a database for the TPM/Trustzone key on their website and make this accessible only for authorized maintainers. The employers could simply get the key based on the camera serial number.

I don't know if any of this will actually happen, but that is a possibility. And, if this happens, this would mean the end of magic lantern... until someone discovers a vulnerability on the TPM module (which has already happen before).

g3gg0

Quote from: names_are_hard on August 21, 2019, 06:18:32 PM
TL;DR - low risk ML gets shut out, but we can only guess.

i am more afraid about the fact that they now look closer and fix other doors we used to get into the cameras :)
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

names_are_hard

Quote from: Luther on August 25, 2019, 07:14:10 PM
Not current cameras. I meant the next generation of cameras.
Ah!  That's the confusion then, sorry, I was talking at cross purposes.  I'm only talking about current cameras; we know they are making changes in the next round of firmware and I was guessing on what I think is most likely.

Quote from: Luther on August 25, 2019, 07:14:10 PM
Do you mean homomorphic? This would imply adding wifi to every camera, including the cheaper ones...
No, just asymmetric.  Homomorphic is witchcraft for the future.  Currently the firmware is AES encrypted, which is symmetric, so the key is in the camera.  In order for ML team to get the camera to load special firmware updates, they have extracted the AES key, which allows creating new firmware.  If Canon used public/private key crypto, it would not be possible to do this; the private key wouldn't be in the camera so couldn't be extracted.

Quote from: g3gg0 on August 25, 2019, 08:14:56 PM
i am more afraid about the fact that they now look closer and fix other doors we used to get into the cameras :)
It's possible.  But probably there are lots of doors :)  And would they really remove debug ports from the boards?  Seems more trouble than it's worth.

g3gg0

Quote from: names_are_hard on August 25, 2019, 09:51:41 PM
It's possible.  But probably there are lots of doors :)  And would they really remove debug ports from the boards?  Seems more trouble than it's worth.
no, i mean software bugs we use.
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

names_are_hard

Quote from: g3gg0 on August 25, 2019, 10:11:29 PM
no, i mean software bugs we use.
Hah, fun :)  You probably have very good odds unless they're in PTP.  And obviously, don't tell anyone what they are :)  Especially not security researchers, they spoil everyone's fun.

g3gg0

Quote from: names_are_hard on August 25, 2019, 11:50:28 PM
And obviously, don't tell anyone what they are :)  Especially not security researchers, they spoil everyone's fun.

yep :)
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

Walter Schulz

Wanted to add 2 or 3 cents and an aspect I think missing in the discussion.

What happened (IMHO)?
A person took his tools and grey matter together and dived into something unknown to discover something. That's what engineers/developers do. We have tools, some busy brain cells and - sometimes - a goal to achieve. Fine. What differs from ML development is POV. He is in the security business and where other people may see a mere bug he saw an opportunity.
Once the attack vector (in PTP) was discovered he may have stopped here. Mathematicians would have: Solution exists -> back to sleep. Okay, telling Canon about it is good practice and within job description. But he didn't stop at this point. Outside the very small community of security geeks such bugs in PTP will not make news. So he thought about something sounding threatening and make people listen. And ransom attack on flash memory content sounds plausible enough and triggered the bigger photog/movie community as intended. (Let's not discuss how far-fetched this scenario is, it is news and therefore solid enough).
As written before: ML offered some kind of paved way to make this happen. Least amount of work compared to other cam manufacturers. Keeping the encryption key hidden was successful and not. As mentioned in the article: Another example security by obscurity doesn't always work.

What will happen (IMHO)?
Pure speculation. Well, ML community may get collateral damage by Canon's action (discussed earlier). It's more difficult for Canon to officially act like ML doesn't exist. We have no saying in the upcoming events.

What are we missing in this discussion(IMO)?
We have no official contacts to Canon. The person discovering the vulnerabilty does now. Maybe we can learn a bit by his approach.
Let's explain my train of thought: A1ex offen mentioned (if I'm remembering correctly) various flaws and potential risks in some firmware routines. Bricked cams by writing nonsense into cam's memory via some not-so-intelligent tools are pretty familiar to him. Canon has no bug-report/bounty program for developers. Maybe they should have.
IMO Canon will have to open up cams to the internet. People want easier access to social media, clouds and other services of their choice. Today they are not well suited for this demand.

May I suggest to think about what ML dev team can do/acchieve by adding security POV into its scope?

Yes, I know there is a major issue within: ML development is endangered by Canon's action against vulnerabilities because ML - somehow - relies on them. It can blast back badly.

But let's give it a try: Take a security POV on firmware/SDK, check for vulnerabilities and if discovered something not exploiding in our face (I have no doubt there are) let us "write home about" (home= Canon). Voilà: Houston, we made contact!


And let us hope Canon doesn't throw ML baby out with the bathwater.

names_are_hard

I am part of the response team for a security bug reporting program for a major company.  I would advise against trying to report security bugs as a means of getting a contact for other purposes.  The biggest reason would be we don't want Canon to associate Magic Lantern with finding security bugs and causing them pain.  But beyond that, if they even have a security bug program, it's not likely to be run by the same people that do normal dev work.  However, when dev work happens in response to a bug, it will normally happen due to assigning items to the standard dev teams...  meaning you just stole time from their feature development work, which managers normally hate.  And now they think that extra work came from Magic Lantern.

If we want to try and get a contact at Canon, just email them and ask.  If you want to submit security bugs, do so as an independent, purely to get the security bugs fixed.

Security researchers are happy to be a little annoying in order to get some PR - that helps them.  We don't want to be annoying and it could hurt us.