5 ms·

In other news, it's 2014 and people still use non-bounds-checked string libraries in C to deal with unvalidated and unauthenticated inputs from a network.

by api 13y ago

sitkack 13y ago
The answer is to stop using C. It doesn't even have to be in Haskell. Hell Lua stops this class of bugs.
- ArkyBeagle 13y ago
  Or you could sanitize the inputs a wee bit. Just a thought. Seems like less a perturbation than rewriting a limited resource device for one feature.
  - masklinn 13y ago
    > Or you could sanitize the inputs a wee bit. If you sanitise inputs a wee bit, chances are you'll forget some. Or some endpoints. Or you'll sanitise based on ASCII but accept non-minimal UTF-8 encoding. Or non-ascii encodings altogether. Making it extremely hard to impossible to implement the error class sounds like a better idea.
    - ArkyBeagle 13y ago
      Not for a cost-constrained network appliance. I think you're overestimating how hard this is. Maybe I'm underestimating it - I've been doing things in a "safe" manner since the 1980s in 'C'. It's second nature to me. And I've never even been interested in UTF-8, much less implemented anything that uses it. I think the OP is a little too cute with "don't use sprintf()" - it and snprintf() can both be used completely safely. Now, it may well be that the UI can be completely done in, say, eLua and the guts of the thing done in 'C'. I'd go for that if it made any sense to any body else on the team. As a practice, I avoid working on things that will be on the larger Internet.
- laichzeit0 13y ago
  If you're building these things it depends what your target market is. How much you want to pay for flash, RAM, packaging, etc. When flash space is a premium (I'm talking 2MB) it becomes a tradeoff between using a tiny C webserver and having a few extra functions or adding a Lua interpreter and dropping those tools. We're talking operating in a margin of a few hundred kilobytes. Also, some of these firmwares are based on an existing code base, it's just cheaper to hack it than replace it.
  - justincormack 13y ago
    openwrt runs Lua, and runs on many of these boxes. It is pretty small and you can cut it down further - eLua runs happily on microcontrollers.
    - sitkack 13y ago
      eLua runs on this board, STM32F4DISCOVERY http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/PF252419 http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/PF252... and is quite easy to setup following instructions from http://www.fussylogic.co.uk/blog/?p=1222 http://www.fussylogic.co.uk/blog/?p=1222

In other news, it's 2014 and people still use non-bounds-checked string libraries in C to deal with unvalidated and unauthenticated inputs from a network.

by api 13y ago

In other news, it's 2014 and people still use non-bounds-checked string libraries in C to deal with unvalidated and unauthenticated inputs from a network.

sitkack 13y ago

The answer is to stop using C. It doesn't even have to be in Haskell. Hell Lua stops this class of bugs.

ArkyBeagle 13y ago
Or you could sanitize the inputs a wee bit. Just a thought. Seems like less a perturbation than rewriting a limited resource device for one feature.
- masklinn 13y ago
  > Or you could sanitize the inputs a wee bit. If you sanitise inputs a wee bit, chances are you'll forget some. Or some endpoints. Or you'll sanitise based on ASCII but accept non-minimal UTF-8 encoding. Or non-ascii encodings altogether. Making it extremely hard to impossible to implement the error class sounds like a better idea.
  - ArkyBeagle 13y ago
    Not for a cost-constrained network appliance. I think you're overestimating how hard this is. Maybe I'm underestimating it - I've been doing things in a "safe" manner since the 1980s in 'C'. It's second nature to me. And I've never even been interested in UTF-8, much less implemented anything that uses it. I think the OP is a little too cute with "don't use sprintf()" - it and snprintf() can both be used completely safely. Now, it may well be that the UI can be completely done in, say, eLua and the guts of the thing done in 'C'. I'd go for that if it made any sense to any body else on the team. As a practice, I avoid working on things that will be on the larger Internet.
laichzeit0 13y ago
If you're building these things it depends what your target market is. How much you want to pay for flash, RAM, packaging, etc. When flash space is a premium (I'm talking 2MB) it becomes a tradeoff between using a tiny C webserver and having a few extra functions or adding a Lua interpreter and dropping those tools. We're talking operating in a margin of a few hundred kilobytes. Also, some of these firmwares are based on an existing code base, it's just cheaper to hack it than replace it.
- justincormack 13y ago
  openwrt runs Lua, and runs on many of these boxes. It is pretty small and you can cut it down further - eLua runs happily on microcontrollers.
  - sitkack 13y ago
    eLua runs on this board, STM32F4DISCOVERY http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/PF252419 http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/PF252... and is quite easy to setup following instructions from http://www.fussylogic.co.uk/blog/?p=1222 http://www.fussylogic.co.uk/blog/?p=1222