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

11–20 of 122 posts

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

#11

Post by wildzzz »

scblock wrote: post #3

The list of fake concerns they list are not the real and very valid concerns I have seen. This addresses nothing.

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 off their ecosystem.

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

#12

Post by geerlingguy »

iLoveOncall wrote: post #10
scblock wrote: post #3

The list of fake concerns they list are not the real and very valid concerns I have seen. This addresses nothing.

The main concern that was raised was that you couldn't send print jobs from other slicers anymore, and this article explains why this isn't the case in the section titled "How Bambu Connect Works", taking OrcaSlicer as an example. How does it not address the concerns of people?

Judging by the PR thread in OrcaSlicer's GitHub repo, not all users are happy with the proposed fix, requiring users to install Bambu Connect on their computers (which currently doesn't run on Linux, IIRC?) to be able to use the new OrcaSlicer to Bambu workflow... https://github.com/SoftFever/OrcaSlicer/pull/8103

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

#13

Post by vvanders »

TechIsCool wrote: post #8

I am surprised that the use of a messaging queue through MQTT is considered a misuse of their technology when in reality it appears that the other application just was using an internal API that could change without notice. I also could see how certificate based authentication could be viewed by some as a time based expiration on the firmware.

Yeah that's a huge bummer if so, I've got both a HA automation that shows the printer status without needing to have an app installed and I've got a secondary filtration system that's fully automated which would be a PITA if I had to manage manually.

Totally understand if it's something that could change/break in future updates but the language about it being "exploited" is a bummer, you would think extending/documenting that would actually drive further adoption of the printers by building a more robust ecosystem around them.

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

#14

Post by rpearl »

wildzzz wrote: post #11
scblock wrote: post #3

The list of fake concerns they list are not the real and very valid concerns I have seen. This addresses nothing.

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…

who cares if Panda Touch/BigTreeTech was making money off the ecosystem? it did nothing more than sell more bambu printers. It's not net-zero--money for BigTreeTech is not coming out of Bambu's pockets; I seriously doubt it was net-negative for Bambu.

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

#15

Post by vvanders »

the_mitsuhiko wrote: post #4
scblock wrote: post #3

The list of fake concerns they list are not the real and very valid concerns I have seen. This addresses nothing.

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

You could already talk freely to the MQTT on the printer and it was already secured with a unique password. This feels like making it a second class feature that could disappear at a future point.

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

#16

Post by blutack »

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 correct, but I'm curious if others can.

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

#18

Post by iLoveOncall »

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…

Look up old results about "BambuLab MQTT" on Google.

They use an online MQTT server instead of the local one for the following functions: initiating printing, heating the nozzle, and heating the heatbed. (see https://www.allaboutbambu.com/2024/06/14/p1p-p1s-new-firmwar...)

On https://forum.bambulab.com/t/bambu-lab-mqtt-limitations/8344... you can see their MQTT server got DDOSed by some faulty 3rd party "client".

I don't think it's so much about security of the users as much as it is about their own.

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

#19

Post by ipv6ipv4 »

geerlingguy wrote: post #12
iLoveOncall wrote: post #10

Earlier quoted context omitted.

The main concern that was raised was that you couldn't send print jobs from other slicers anymore, and this article explains why this isn't the case in the section titled "How Bambu Connect Works", taking OrcaSlicer as an example. How does it not address the concerns of people?

Judging by the PR thread in OrcaSlicer's GitHub repo, not all users are happy with the proposed fix, requiring users to install Bambu Connect on their computers (which currently doesn't run on Linux, IIRC?) to be able to use the new OrcaSlicer to Bambu workflow... https://github.com/SoftFever/OrcaSlicer/pull/8103

Tellingly, this pull request is coming from a Bambu Lab employee. I think the OrcaSlicer maintainers should tell Bambu Lab to pound sand with this change.

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

#20

Post by ClassyJacket »

Hizonner wrote: post #17

Uh-huh. So exactly what threat or threats is the "security upgrade" meant to address, what alternatives were considered, and where the heck is the "security" in sticking a barely obfuscated private key in a publicly distributed binary?

The threat of Bambu not being able to remotely brick your printer in 5 years when they want to sell you a new one
Post reply on HN