Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bambu Lab - Setting the Record Straight About Our Security Update

blog.bambulab.com

Post reply on HN
Print view View original

81–90 of 122 posts

Re: Bambu Lab - Setting the Record Straight About Our Security Update

#81

Post by the_mitsuhiko »

ipv6ipv4 wrote: post #27
iLoveOncall wrote: post #23

Earlier quoted context omitted.

> I think the OrcaSlicer maintainers should tell Bambu Lab to pound sand with this change. Hum, the alternative is OrcaSlicer stops working with Bambu printers...

You mean Bambu Lab broke compatibility with OrcaSlicer and every other slicer out there. I don't know if the OrcaSlicer maintainers feel this way. But if they feel that Bambu Lab is stabbing them in the back, they don't have to jump when Bambu Lab tells them to (that's pretty much the raison d'être of open source).

I'm guessing most of OrcaSlicer's users are using bambu printers and if they upgrade to the firmware that requires bambu connect it's quite likely that the OrcaSlicer maintainers will have some interest in keeping the slicer working.

The alternative is that users have to manually use bambu connect and that seems inferior to what the PR enables.

Re: Bambu Lab - Setting the Record Straight About Our Security Update

#82

Post by the_mitsuhiko »

KMnO4 wrote: post #66
aweiland wrote: post #55

Earlier quoted context omitted.

Prusa

Prusa does not have an equivalent printer to the P1S/X1C. Even their Mk4s is twice the price of an A1 and is missing some basic features that come standard on all Bambu Lab printers (such as a camera).

Prusa Core One exists.

Re: Bambu Lab - Setting the Record Straight About Our Security Update

#83

Post by the_mitsuhiko »

barbazoo wrote: post #74
mmorriso wrote: post #53

Earlier quoted context omitted.

I use LAN mode for my P1S currently in a shed with a local AP and no internet access and it works fine.

https://www.youtube.com/watch?v=91kfolYkRNM Says even then you have to use their app and cloud service to set up the printer.

I don't think this is correct. I'm fairly certain you can enable LAN only mode without signing in on the printer.

Re: Bambu Lab - Setting the Record Straight About Our Security Update

#84

Post by reimertz »

We were about to to buy a Bambu Lab printer but then learnt there will be new printers coming out in Q1 so naturally wanted to wait.

I need to educate myself on this a bit more on this issue, but it feels like the rest of the printer industry is just catching up with the X1C (looking at Creality K2 Plus)..

Do I wait for next-gen printers from Bambu Labs which I imagine will be quite revolutionary, or do I buy we buy a Creality K2 Plus, which basically is a X1C.

Re: Bambu Lab - Setting the Record Straight About Our Security Update

#85

Post by blutack »

parasubvert wrote: post #68
Maskawanian wrote: post #63

Earlier quoted context omitted.

MQTT is not inherently insecure. Much like HTTP, there is a encrypted version that runs on port 8883.

That... doesn't make things particularly secure. First of all MQTT doesn't require authentication. Secondly FTP is involved which is generally deprecated on most sensible servers and networks. Finally, sending passwords in the clear over an encrypted wire to an end device has been an obsolete technique for over 20 years. People still do it, but they shouldn't. It's the reason we have Kerberos, OAuth2/OIDC, and x509 c…

If MQTT is fundamentally insecure, someone needs to inform the AWS IoT and Azure IoT teams.

While they are at it, they need to change their user admin consoles to only allow access via mTLS rather than sending "plain text" passwords over HTTPS as part of their OAuth 2.0 logins.

Yes, hyperbole, but there are many threat models and mTLS isn't some magic panacea, there are tough issues around key deployment and management which Bambu obviously haven't thought through.

https://docs.aws.amazon.com/iot/latest/developerguide/mqtt.h...

Just like HTTP, there will always be someone who manages to misconfigure or turn off all the security. That doesn't make the protocol bad or irrelevant.

The majority of deployed MTLS certificates I've seen in the wild are used in IoT contexts to auth against MQTT servers because of the many advantages MQTT has over HTTPS for that use case.

Re: Bambu Lab - Setting the Record Straight About Our Security Update

#86

Post by parasubvert »

blutack wrote: post #85
parasubvert wrote: post #68

Earlier quoted context omitted.

That... doesn't make things particularly secure. First of all MQTT doesn't require authentication. Secondly FTP is involved which is generally deprecated on most sensible servers and networks. Finally, sending passwords in the clear over an encrypted wire to an end device has been an obsolete technique for over 20 years. People still do it, but they shouldn't. It's the reason we have Kerberos, OAuth2/OIDC, and x509 c…

If MQTT is fundamentally insecure, someone needs to inform the AWS IoT and Azure IoT teams. While they are at it, they need to change their user admin consoles to only allow access via mTLS rather than sending "plain text" passwords over HTTPS as part of their OAuth 2.0 logins. Yes, hyperbole, but there are many threat models and mTLS isn't some magic panacea, there are tough issues around key deployment and manageme…

I didn't say "inherently" or "fundamentally" insecure in my post. I said "generally". Generally, it's hard to deploy MQTT in a secure way, as it has many options that are insecure. In particular, you'll want to use mTLS, which itself is tricky to deploy due to the need for client cert verification. MQTT without mTLS is also prone to DDOS with less widely known techniques for mitigation than HTTPS.

The public HTTP web generally doesn't need client authentication, most just want server authentication, and thus it's a bit easier to deploy and use 3rd party services to mitigate DDOS attacks.

Re: Bambu Lab - Setting the Record Straight About Our Security Update

#87

Post by blutack »

parasubvert wrote: post #41

People seem to be missing that FTP and MQTT are generally insecure protocols. I think FTP is probably the bigger issue than MQTT. This kind of stuff is common in home IOT networks but would never pass security audit on a corporate network. Bambu is growing up, serving more corporations beyond the hobby community, and probably has been asked to beef their security up to make it easier to deploy their printers securely…

- Hey here is our new laser printer

- You can't print from Office you need to export to a PDF

- Then use our SecurePrintTM application to send your PDF to the printer. It uses a hard coded mTLS key to talk to our cloud so it's super safe.

- Also SecurePrintTM sends all your PDFs through our servers where we could read them because we control all the keys. We promise we won't though. Don't worry, they are mTLS encrypted on the way to our cloud!

I do understand your point - the current implementation of LAN mode would not be suitable for enabling on a network with very high security requirements. I just don't understand how Bambu think this improves things.

Why not add user controlled OAuth/mTLS to the X1E? Hell, make it additional paid extra. Right now, it seems like their new approach is worse for everyone.

Re: Bambu Lab - Setting the Record Straight About Our Security Update

#88

Post by BeefWellington »

progbits wrote: post #7
the_mitsuhiko wrote: post #4

Earlier quoted context omitted.

> This addresses nothing. This does in-fact address quite a bit, because they have change their stance with this update. Previously even LAN only mode required to go via their bambu connect system, now you can switch it to developer mode and talk freely via MQTT to the printer.

But when you buy the printer you still need to give it internet access / connect via their app, right?

You do not need to give it internet access for LAN mode to function, but you lose a LOT of features that the cloud app and mobile app give you. For example, you can no longer do anything with the camera in LAN mode, even from the official Bambu Studio app. So no timelapses or ability to check in on it from even just elsewhere in my house.

There's also other limitations of it in features I don't really use, for example IIRC the RFID stuff they do with their print spools stops working.

Re: Bambu Lab - Setting the Record Straight About Our Security Update

#89

Post by ipv6ipv4 »

parasubvert wrote: post #80
ipv6ipv4 wrote: post #75

Earlier quoted context omitted.

If this were about security, it wouldn't matter what piece of software was implementing the well documented security protocol. BambuSlicer, or OrcaSlicer, it would be all the same because the underlying protocol would be the security guarantee. This is rudimentary security tradecraft. Bambu Lab is introducing something else. Most charitably, it could be described as security through obscurity, which is never secure.…

Controlling the software lifecycle of a client library or executable, to be able to update its x509 certs as part of an upgrade cycle, is ... not security through obscurity. It's pretty standard practice, especially if your customer base knows very little about maintianing certs/keys. It's about a vendor trying to control an experience for its users balancing its UX and maintenance costs. There's no real vendor lock-…

Somehow you can securely access your bank account with any browser of your choosing, and not a bank provided browser, but 3D printers need obscure proprietary security protocols to be secure. That doesn't make sense.

Re: Bambu Lab - Setting the Record Straight About Our Security Update

#90

Post by BeefWellington »

parasubvert wrote: post #57
blutack wrote: post #48

Earlier quoted context omitted.

I wasn't aware of any specific vulnerabilities in the basic MQTT design (assuming it's over TLS). I agree that MTLS for embedded m2m/IOT auth against MQTT is pretty standard (see AWS IOT, Azure etc) but do paper printers used in enterprise which have displays typically require MTLS for printing? Surely any corporation with a security team would VLAN and null route these things anyway - only the enterprise targeted X1…

I don't think their MQTT was over TLS traditionally (maybe they added this), it used to be that you just sent a message over unauthenticated MQTT and FTP'd your 3MF; the FTP had a password but that also was sent in the clear. https://github.com/darkorb/bambu-ftp-and-print Most corps these don't want to deal with the hassle of VLANs and black holes for insecure devices.

People have been using MQTT with TLS for years[1][2][3]. Long before the company and line of printers existed. It's not really an excuse to say "well they didn't use it" -- they should have simply offered people the necessary configuration options to enable it.

[1]: https://mosquitto.org/blog/2018/05/version-1-5-released/ [2]: https://forums.raspberrypi.com/viewtopic.php?t=287326 [3]: https://esp32.com/viewtopic.php?t=9747

Post reply on HN