[FR] Security audit of the code

[DemiMarie]

Is your feature request related to a problem? Please describe.

Right now, most printers do not appear to have hardware interlocks to prevent compromised firmware from causing physical damage or unsafe conditions.

Are you looking for hardware support?

No

Describe the feature you want

I would like to be confident that the firmware cannot be compromised via any of the following:

• Malicious USB devices
• Malicious SD cards
• Malicious G-code

Firmware updates that are authorized by the user are of course excepted.

Additional context

I recommend a security review of all parts of the code that process external input. The G-code parser is by far the most critical, but the USB stack and filesystem parsers are also important.

[DerAndere1]

Not what you want to hear but IMHO still required disclaimer: Marlin cannot be safe to use if your printer does not have least one of the following:

• both, min- AND max-limit switches on all axes.
• hardware and electronics designed to endure crashes of the tool into the frame or bed and extended periods of motor stalling
• Low enough MAX_FEEDRATE_EDIT_VALUES

there is no other way to exclude physical damage caused by G-code containing M121 (disables software endstops). Also, you could always send G-code scripts that cause the heaters to continuously maintain e.g. 180 °C for for a long time (days, weeks). We cannot expect that all DIY printers are designed to stay safe under such circumstances. So you must

• physically prevent access to the machine by unauthorized/uneducated people.
• install an automated alarm system and automated fire extinguishers or supervise the printer
• Install a panic button
• For printers shared by different persons. establish your own set of rules for usage based on your own risk analysis (depends on printer capabilities)

Remember that the GPL License excludes any warranty and liability by the Marlin devs.

[DemiMarie]

G-code containing M121 (disables software endstops)

Can support for this be disabled? It seems like a dangerous feature.

Remember that the GPL License excludes any warranty and liability by the Marlin devs.

I know. The proper fix is hardware interlocks that work even if the software is malicious. It should not be possible for bad software to place the hardware in an unsafe condition. That said, I believe my desire that Marlin be secure is still a valid one.

[DerAndere1]

A minimalistic way to disable support for M121 would be to change https://github.com/MarlinFirmware/Marlin/blob/9778b67e84b1ff022669b7327a297d6cd44d4ed2/Marlin/src/gcode/gcode.cpp#L656 to this:

#if DISABLED(ENDSTOPS_ALWAYS_ON)
   case 121: M121(); break
#endif

and somewhere (e.g. in file Configuration_adv.h) add the following:

#define ENDSTOPS_ALWAYS_ON

in addition, make sure to enable the already existing option in Configuration_adv.h:

#define ENDSTOPS_ALWAYS_ON_DEFAULT

[DerAndere1]

G-code M303 can be abused to allow cold extrusion. This can damage the extruder. To disable M303 support, changes similar to those suggested for M121 have to be made.

Regarding treatment of malicious storage devices and USB, other people will have to comment. I assume that so far. the expectation was that all devices and media that are connected to the printer were previoulsy checked on a PC using anti-virus software and tools for checking for data integrity.

[thinkyhead]

Marlin is generally secure when it is placed in a secure environment and used as intended, but there are probably a thousand things you could do to damage the printer just by running G-code, such as continuously running the carriage past the limits, turning up the heat to temperatures that can cook PTFE, running the E axis continually to use up all the filament in the roll, and so on.

Securing everything is a project which anyone is free to undertake according to their level of interest and skill. At this moment, there is no one around who is prepared to spearhead that project, at least not until the workload abates.

[descipher]

No 3D firmware product on the market today can provide security from:

Malicious USB devices Malicious SD cards Malicious G-code

when there is physical or network access.

[DemiMarie]

In this case, I think that Marlin should document what safety features a 3D printer’s hardware should be expected to have, so that a bug in the firmware cannot cause a safety hazard. Hardware stop switches and thermal shutdown are the ones that immediately come to mind.

[ellensp]

Marlin is a community driven and contributed project. Ie we are all volunteers. If you want these things documented to your standards. The best way is to do it yourself.

Or wait patiently, potentially forever, for a like minded individual with the capabilities and the motivation and the time to do it for you.

[artemician]

In this case, I think that Marlin should document what safety features a 3D printer’s hardware should be expected to have, so that a bug in the firmware cannot cause a safety hazard. Hardware stop switches and thermal shutdown are the ones that immediately come to mind.

Um what? It's open source, you are calling for Marlin to regulate printers... I don't think you quite understand how printers work... it's not Marlins responsibility to tell manufacturers what features they have to have. I think you need to find a different hobby

[github-actions[bot]]

This issue has had no activity in the last 60 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 10 days.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.