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

111–120 of 122 posts

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

#111

Post by parasubvert »

1116574 wrote: post #97
parasubvert wrote: post #72

Earlier quoted context omitted.

Generally speaking, no. Prusa comes close - they're dedicated to community and OSS, and are quality parts... but are almost 2x the price and tend to be missing comparable features. The other competition doesn't quite have the UX and quality of Bambu Lab. That's changing slowly, but it's reality today IMO. The challenge is that the 3d Printing community is maturing from a hobbyist/tinker phase into a consumer phase wi…

How do normal paper printers work on such networks? From what I gather there is some standardised solution to that, wherein here bambu requires their own "connect" software, correct? I think that big enterprises are full of old systems that are put on vans, vpns, conditional access rules etc., so it's weird to me that ftp is such a problem? There is also a point in their tos: 7.4 - boils down to "your printer will bl…

Normal paper printers concentrate print services to a Windows or Linux print server that authenticates users before they submit a job. All the direct ports on the printer are firewalled and restricted to the print server.

The main issue is that paper printers are a terrible legacy technology that didn't evolve much and are grandfathered into corporate security, whereas any new technology or new vendors have a much higher bar to pass before they're let on networks. Yes, there are many workarounds like VLANs, firewalls and black hole routes etc but they're usually treated as exceptions these days.

The TOS is meant to cover worst case scenarios, such as, the x509 certificates on the printer expire, or a major vulnerability is found. The printer is a hybrid cloud connected or LAN connected service and thus it's reasonable to warn users they need to update periodically because Bambu doesn't want to be exposed by for unpatched backdoor attacks etc. This is a similar issue with MacOS or Windows where you cant use your web browser securely after a few years of missing updates, or other connected devices where you must consent to automatic updates to use the device (Google Nest or Amazon Ring devices come to mind). Bambu is actually being better than most device companies in that they are just requiring this for crucial security updates and they don't require an internet connection: you can patch it via SD Card.

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

#112

Post by parasubvert »

ipv6ipv4 wrote: post #89
parasubvert wrote: post #80

Earlier quoted context omitted.

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.

That's because the bank isn't generally using mutual TLS client authentication to verify your account details through your browser. You login with a password and other authentication factors .

Interestingly some banks do use x509 client authentication for corporate accounts or high net worth accounts but they expect you to know how to import the key to your browser. And almost all banking mobile apps use this to call their server APIs to ensure only the Bank's mobile apps (or partners) can call their APIs.

In Bambu Labs' case, they've had many DDOS attacks and other issues with their security and so they're forcing a constraint on the approved software clients that can access their printers and/or cloud service via client authentication. BambuConnect being the catch all proxy software for most.

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

#113

Post by ipv6ipv4 »

parasubvert wrote: post #112
ipv6ipv4 wrote: post #89

Earlier quoted context omitted.

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.

That's because the bank isn't generally using mutual TLS client authentication to verify your account details through your browser. You login with a password and other authentication factors . Interestingly some banks do use x509 client authentication for corporate accounts or high net worth accounts but they expect you to know how to import the key to your browser. And almost all banking mobile apps use this to call…

None of this makes sense.

Bambu is forcing its customers to use its cloud offerings when many users want to use the machine on their LAN without the cloud guff. Many for security reasons. Bambu essentially tells its customers to pound sand, they are forced to use cloud. Now Bambu is claiming it has a cloud DDOS problem and therefore it is going to lock down what users can do further. I'm sorry, that's just silly. Let me connect to the printer locally, and your cloud DDOS problems go away.

The DDOS problem itself doesn't sound particularly compelling as a justification for this action, either. If every user action is authenticated, you know which users are abusing the system - throttle them or kick them out. Adding a TLS certificate for mutual authentication is going to reduce the DDOS overhead by a negligible amount.

> forcing a constraint on the approved software clients

Which will do nothing against a determined DDOSer since they will always be able to extract the certificates from Bambu Connect, or BambuSlicer.

Finally, if the issue is airtight security for the on-prem printer and preventing a hacker external or internal to the LAN from exploiting them. Maybe Bambu can take a page from the Matter smart home specs. if they are out of ideas. These are solved problems. Cloud not necessary. Software lockdown not necessary.

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

#114

Post by ipv6ipv4 »

the_mitsuhiko wrote: post #100
ipv6ipv4 wrote: post #91

Earlier quoted context omitted.

> 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. Yes. That's where the maintainers need to decide if they are Bambu Lab's lackeys or if they have a say in their beloved project. Part of that is thinking about at what point the projec…

> Yes. That's where the maintainers need to decide if they are Bambu Lab's lackeys or if they have a say in their beloved project. I understand your anger, but I don't think that properly describes the situation. As a maintainer of an open source project your users are who you are about. If your users want support for bambu connect, then you are likely to implement it. Whatever Bambu does is whatever Bambu does, you…

I generally agree with your view on OrcaSlicer. I think we have a difference on what is better for the users and the project itself. I think it is better for the users if the maintainers take a stand against Bambu's dictat.

> Whatever Bambu does is whatever Bambu does, you need to accept it.

And maybe it is time to take your ball and go home.

> What would Bambu's motivation be to do that?

What is Bambu's motivation for being cloud first when it is not technically necessary? Why can't OrcaSlicer be a first class citizen like BambuSlicer? Instead it has to go through Bambu Connect which is inherently clunky and less featureful. It's simple. Control, and vendor lock-in. Possibly, Bambu sees this as a way to curtail print farm automation software from other vendors.

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

#116

Post by hWuxH »

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-…

ppl always get caught up on the x509. They're actually a good thing and are absolutely necessary to prevent mitm since they use self-signed certs. BambuStudio also works that way.

The issue is introducing further measures which don't provide any security benefit to the user (can be spoofed): only allowing critical commands from BambuConnect.

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

#117

Post by hWuxH »

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.

Everything was sent in plaintext early on. But since 2022/2023 it's TLS: https://wiki.bambulab.com/en/security-incidents-cloud-traffi...

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

#118

Post by hWuxH »

blutack wrote: post #16

Does anyone know or can see an actual concrete security concern with the current implementation of LAN mode? https://github.com/Doridian/OpenBambuAPI/blob/main/mqtt.md Right now, the printer's local MQTT server can only be accessed from the local IP using an 8 digit password obtained through through the physical display. I can't personally see any fundamental issue with this design assuming the implementation is corr…

> Right now, the printer's local MQTT server can only be accessed from the local IP using an 8 digit password obtained through through the physical display.

The problem is hackers don't need to play by the rules (accessing the display).

8 digits that never change is a joke in terms of security, it could be brute-forced within hours/days by sending a network request for each possible combination.

mitm: afaik Bambu Studio/Connect/Handy validate the printer's certificate during the TLS handshake, but most third party software probably doesn't (barely found documentation about it).

And there are a few other (although not as fundamental) weaknesses like no mutual authentication, access control or revocation of specific clients. Due to the nature of MQTT, every client can see messages sent by other clients once authenticated.

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

#119

Post by hWuxH »

sho_hn wrote: post #64
parasubvert wrote: post #59

Earlier quoted context omitted.

You don't need to. You can use their Bambu Connect client in LAN mode. Or you can turn off security and use "developer mode", aka. "how things work today" mode, if you want to do things the old / insecure way.

Insecure for who? What's the threat vector?

I wouldn't call it more or less secure. You're just on your own and should expect this (internal) API to have breaking changes at any time.

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

#120

Post by hWuxH »

VogonPoetry wrote: post #67
wildzzz wrote: post #11

Earlier quoted context omitted.

These companies always pick the most ridiculous tinfoil hat bullshit list of complaints to debunk when trying to explain why they want to close off their API. The real reason almost always comes down to money. The mention of Panda Touch is very telling. While I'm sure Bambu doesn't want to maintain documentation for a non-public (is that the right term)? API, they definitely don't want other companies making money of…

What if this is not about closing off an API. Maintaining a stable API is difficult - especially if mistakes were made in earlier designs (no versioning, bad abstraction, wrong protocol...) and there is a plan to fix things in the future. Only the maintainer of an API knows what the future plans are. Not making future plans public is the way to avoid Osbourne incidents and to actually deliver real things, not just va…

> What if this is not about closing off an API. Maintaining a stable API is difficult

That's why any sane software uses a stable public API and an internal one that can be closed off or has breaking changes all the time.

> MQTT has no versioning and limited hierarchy in the pub / sub model

It's currently handled like this: https://github.com/Doridian/OpenBambuAPI/blob/main/mqtt.md. Would it be a far stretch to add an "api_version":x field and a "internal_" prefix for some commands?

Post reply on HN