general security considerations for televex print #1

New Issue

rra · 2021-02-24T21:45:05+01:00

rra commented

2021-02-24 21:45:05 +01:00

Hi all,

here is an issue that lists some general security considerations that we should take in to account when doing diy internet of things:

unsanitized input

L:79 of start.py passes whatever input directly to the printer. This will include certain control sequences or characters that could do anything ranging from:

changing the character set
exposing control functions we dont know of
print out the entire roll of paper
disable / damage the machine

Additionally the following questions arise:

will the device interpret certain things differently than you thought? Can it be programmed like this?
can the device be used to send commands to the varia server?

See for example https://en.wikipedia.org/wiki/Control_character for ascii control characters. Classics include the bell, and the form feed :)

everyone can write to the device

Currently the page is completely open for anyone on the internet to write to it. Is that intended?

There is also no check of any of the following:

how often someone prints
where print commands are originating from are coming from
the length of the message ( ;) )

device produces heat

the device is based on heating an element to print on the paper.

Is there a fire risk when the device is always on?
when it malfunctions?
when it is used excessively?
How is this risk changed by the headings mentioned above?

None of these things are to say one shouldn't do it

but it is good to consider all of the above and mitigate risks.

Hi all, here is an issue that lists some general security considerations that we should take in to account when doing diy internet of things: ## unsanitized input L:79 of start.py passes whatever input directly to the printer. This will include certain control sequences or characters that could do anything ranging from: * changing the character set * exposing control functions we dont know of * print out the entire roll of paper * disable / damage the machine Additionally the following questions arise: * will the device interpret certain things differently than you thought? Can it be programmed like this? * can the device be used to send commands to the varia server? See for example https://en.wikipedia.org/wiki/Control_character for ascii control characters. Classics include the bell, and the form feed :) ## everyone can write to the device Currently the page is completely open for anyone on the internet to write to it. Is that intended? There is also no check of any of the following: * how often someone prints * where print commands are originating from are coming from * the length of the message ( [ ;) ](https://peertube.social/videos/watch/36e0850b-b5be-4f06-b824-b191e4054c88) ) ## device produces heat the device is based on heating an element to print on the paper. * Is there a fire risk when the device is always on? * when it malfunctions? * when it is used excessively? * How is this risk changed by the headings mentioned above? ## None of these things are to say one shouldn't do it but it is good to consider all of the above and mitigate risks.

rra commented

2021-02-24 21:46:23 +01:00

also the code running on the device is visible publicly in this git repo. Is that an issue?

rra changed title from ~~general security considerations~~ to general security considerations for televex print

2021-02-24 21:48:06 +01:00

then commented

2021-02-24 22:17:58 +01:00

Great point, I did not get around to get involved in this project but I was wondering if the setup is always powered on? If so i suggest to add a timer to automatically power up and shutdown the setup. I might have some lying around here.

crunk commented

2021-02-24 22:19:21 +01:00

good points rra, in general I think we should be aware of these things when writing software that is open to the outside. And I think this could be a good test case since.

the project is really unknown, the chances of problems are pretty low
the code is unique, so there are no scripts already made for its vulnerabilities.

As far as I know the code is also on a seperate machine, so thats good too.

My biggest concern would be being able to escape the functionality of printing a line. can I escape and execute shell code? can I escape and insert html or js?
The printed material is on a page too, what if I corrupt that json file?

I am wondering
how much the input is sanitized by flask?
how much the input is sanitized by L:74 and L:82, a printer buffer and line printing raw text?

especially flask is good to know, because we use it pretty often. Its good to be aware of what security it does and doesn't do for you.

good points rra, in general I think we should be aware of these things when writing software that is open to the outside. And I think this could be a good test case since. 1. the project is really unknown, the chances of problems are pretty low 2. the code is unique, so there are no scripts already made for its vulnerabilities. As far as I know the code is also on a seperate machine, so thats good too. My biggest concern would be being able to escape the functionality of printing a line. can I escape and execute shell code? can I escape and insert html or js? The printed material is on a page too, what if I corrupt that json file? I am wondering how much the input is sanitized by flask? how much the input is sanitized by L:74 and L:82, a printer buffer and line printing raw text? especially flask is good to know, because we use it pretty often. Its good to be aware of what security it does and doesn't do for you.

crunk commented

2021-02-24 22:32:56 +01:00

also the code running on the device is visible publicly in this git repo. Is that an issue?

In my (utopian) opinion, you shouldn't need to hide your code in order to addresss security concerns.

Thats because most security problems come from scripts, they will try to just insert js code into a text field and the js code will tell them it was a success (by forwarding a user to their server for example)

the script will try that regardless of your code being on git or not.
*just be careful putting apikeys, passwords etc on gits. :)

> also the code running on the device is visible publicly in this git repo. Is that an issue? In my (utopian) opinion, you shouldn't need to hide your code in order to addresss security concerns. Thats because most security problems come from scripts, they will try to just insert js code into a text field and the js code will tell them it was a success (by forwarding a user to their server for example) the script will try that regardless of your code being on git or not. *just be careful putting apikeys, passwords etc on gits. :)

rra commented

2021-02-24 22:47:37 +01:00

good points rra, in general I think we should be aware of these things when writing software that is open to the outside. And I think this could be a good test case since.

the project is really unknown, the chances of problems are pretty low

the code is unique, so there are no scripts already made for its vulnerabilities.

As far as I know the code is also on a seperate machine, so thats good too.

Yes!

My biggest concern would be being able to escape the functionality of printing a line. can I escape and execute shell code? can I escape and insert html or js?
The printed material is on a page too, what if I corrupt that json file?

I am wondering
how much the input is sanitized by flask?
how much the input is sanitized by L:74 and L:82, a printer buffer and line printing raw text?

especially flask is good to know, because we use it pretty often. Its good to be aware of what security it does and doesn't do for you.

Flask does a lot of HTML escaping already automatically against XSS. So that is good. However not sure that covers things wrt the printer.

Also if you say we shouldn't be hiding the code but also assume the chance of problems is low because the project is not well known there is a contradiction :)

> good points rra, in general I think we should be aware of these things when writing software that is open to the outside. And I think this could be a good test case since. > 1. the project is really unknown, the chances of problems are pretty low > 2. the code is unique, so there are no scripts already made for its vulnerabilities. > > As far as I know the code is also on a seperate machine, so thats good too. Yes! > My biggest concern would be being able to escape the functionality of printing a line. can I escape and execute shell code? can I escape and insert html or js? > The printed material is on a page too, what if I corrupt that json file? > > I am wondering > how much the input is sanitized by flask? > how much the input is sanitized by L:74 and L:82, a printer buffer and line printing raw text? > > especially flask is good to know, because we use it pretty often. Its good to be aware of what security it does and doesn't do for you. Flask does a lot of HTML escaping already automatically against XSS. So that is good. However not sure that covers things wrt the printer. Also if you say we shouldn't be hiding the code but also assume the chance of problems is low because the project is not well known there is a contradiction :)

crunk commented

2021-02-24 23:04:22 +01:00

Also if you say we shouldn't be hiding the code but also assume the chance of problems is low because the project is not well known there is a contradiction :)

:) that is very true, but I meant one in a specific sense and the other in a generic sense, security by obscurity etc. (I think this idea is great! Because I can imagine myself working in Varia in the future and then being able to shout, incoming message on the Televex! and then run to the printer)

and it also presents a possibility to discuss security issues in this thread, so we can learn from it and improve code as we go.

so on L:45 the function html2plain uses regex for stripping html from the rss feeder text. which is fine because its from our own rss feeds. But in general the good practice would be to use a library for that and not regex, because regex will never truly do a good job.
best is to just use a library like HTMLParser or xml.etree
as suggested here: https://stackoverflow.com/questions/753052/strip-html-from-strings-in-python

in answer number 2 someone also get angry because yet another upvoted suggestion to use regex for this :)

> Also if you say we shouldn't be hiding the code but also assume the chance of problems is low because the project is not well known there is a contradiction :) > :) that is very true, but I meant one in a specific sense and the other in a generic sense, security by obscurity etc. (I think this idea is great! Because I can imagine myself working in Varia in the future and then being able to shout, incoming message on the Televex! and then run to the printer) and it also presents a possibility to discuss security issues in this thread, so we can learn from it and improve code as we go. so on L:45 the function html2plain uses regex for stripping html from the rss feeder text. which is fine because its from our own rss feeds. But in general the good practice would be to use a library for that and not regex, because regex will never truly do a good job. best is to just use a library like HTMLParser or xml.etree as suggested here: https://stackoverflow.com/questions/753052/strip-html-from-strings-in-python in answer number 2 someone also get angry because yet another upvoted suggestion to use regex for this :)

then commented

2021-02-25 16:21:33 +01:00

I brought a 220v programmable timer to the space. The pi must be synced with this tho (startup script and shutdown before the power cuts)

mb referenced this issue from CC/octomode

2022-02-17 13:46:35 +01:00

Consider security and possible forms of misuse of octomode #2

Sign in to join this conversation.