7 ms·

It's great that these bugs have been found and fixed. I'm frightened by this report however. If a well managed open-source project like Curl has this number o

by nas 10y ago

It's great that these bugs have been found and fixed. I'm frightened by this report however. If a well managed open-source project like Curl has this number of pretty serious bugs that can be found by skilled auditors, what hope do we have of securing ourselves against state sponsored attacks? Really no hope, I think. Given the amount code on a modern computer, there must be no shortage of "zero-day" holes they can use. Maybe this is not news to most informed people. It shocks me though. I know the situation is bad, just didn't fully grok how bad.

elmigranto 10y ago
Creating 100% secure software is not realistic. If you can't win, change the game. I'm not saying you should give up or that audits are a waste. They are a good thing, though you should also work on other approaches to the problem besides "work harder on security bugs".
perlgeek 10y ago
This is one of the reasons that people are excited about Rust; it promises to eliminate a whole class of security bugs that are often found in C applications and libraries. Without having to resort to managed code.
- petters 10y ago
  Completely agree. The first issue in the report is about reading lines from a file. Those kinds of bugs can and should be eliminated for good.
- pjmlp 10y ago
  > Without having to resort to managed code. Which was already partially possible in the last decades by the lines of Algol family of languages starting on the Mesa/Cedar and Ada branches. What is more exciting about Rust is that a new generation of coders is rediscovering the ways of system programming before C took over the IT industry. Also how their efforts to adopt Cyclone regions are influencing Swift, C++, D, ParaSail and Pony designs.
- cesarb 10y ago
  > Without having to resort to managed code. Even better: gradually replacing parts of the current C code with Rust code is possible, while keeping the same API and ABI. IIRC, someone is already trying it with librsvg.
  - steveklabnik 10y ago
    https://people.gnome.org/~federico/news-2016-10.html#25 https://people.gnome.org/~federico/news-2016-10.html#25
laumars 10y ago
While you are right, you can approach security from graded risk perspective. eg non-validated user input on an internet facing interface is going to be a greater risk than a buffer overflow bug in cron (for example). So when hardening your systems the first thing you do is limit the amount of access the outside world has to your OS and application and ansure that all components that do access the outside world are up-to-date (curl is one of those libraries which would communicate to the outside world). So firewalling, OS updates, decent bit lenghs on your encryption keys, etc. Then you ensure all your applications are sandboxed so even if they are exploited the scope of data they can do is limited. But as you said, a sufficiently competent and determined hacker will likely find a way into many a "secure" system. But if you can limit the code that is exposed to the internet then you at least limit the amount of code that can be exploited (or rather force an attacker to use more than one attack in conjunction to gain system access). However if an attacker has physical access to your system then I'd just give up now as you've already lost.
tptacek 10y ago
There's pretty much no good reason that the most widely used command line HTTP fetcher should be a giant C project.
- rini17 10y ago
  For libcurl - easy linking to any C/C++ code is very good reason. And standalone curl is lighweight with minimal system dependencies.
  - tptacek 10y ago
    I understand libcurl well (I've used it before on projects), and don't dispute its utility. I also understand the value of a very small C-based HTTP fetcher for system bootstrapping (I'm not sure that's really what curl is). What I don't get is why the most widely used general purpose command line HTTP fetcher is a giant C program that we're still finding UAFs in in 2016. I respect the enormous effort that goes into maintaining curl (though I have my differences with the way security is handled). But it's past time curl is replaced by a Rust or Go program.
    - tomcam 10y ago
      You're a pretty smart guy. Why not just knock out that little baby yourself?
      - tptacek 10y ago
        I'm hoping someone else already is.
        JoachimSchipper 10y ago
        You might want to consider OpenBSD's ftp. It does a lot more than FTP.
    - shakna 10y ago
      A statically linked curl for ARM64 is 205kb. A statically linked hello world in Rust for ARM64 is 680kb. Curl is used for a ton of embedded hardware, and is probably in your router. Until Rust can solve its massive binaries, that is somewhere on their roadmap, it just isn't appropriate for use in the embedded world, where kilobytes still count.

by nas 10y ago

elmigranto 10y ago

Creating 100% secure software is not realistic. If you can't win, change the game. I'm not saying you should give up or that audits are a waste. They are a good thing, though you should also work on other approaches to the problem besides "work harder on security bugs".

perlgeek 10y ago

This is one of the reasons that people are excited about Rust; it promises to eliminate a whole class of security bugs that are often found in C applications and libraries. Without having to resort to managed code.

petters 10y ago
Completely agree. The first issue in the report is about reading lines from a file. Those kinds of bugs can and should be eliminated for good.
pjmlp 10y ago
> Without having to resort to managed code. Which was already partially possible in the last decades by the lines of Algol family of languages starting on the Mesa/Cedar and Ada branches. What is more exciting about Rust is that a new generation of coders is rediscovering the ways of system programming before C took over the IT industry. Also how their efforts to adopt Cyclone regions are influencing Swift, C++, D, ParaSail and Pony designs.
cesarb 10y ago
> Without having to resort to managed code. Even better: gradually replacing parts of the current C code with Rust code is possible, while keeping the same API and ABI. IIRC, someone is already trying it with librsvg.
- steveklabnik 10y ago
  https://people.gnome.org/~federico/news-2016-10.html#25 https://people.gnome.org/~federico/news-2016-10.html#25

laumars 10y ago

While you are right, you can approach security from graded risk perspective. eg non-validated user input on an internet facing interface is going to be a greater risk than a buffer overflow bug in cron (for example). So when hardening your systems the first thing you do is limit the amount of access the outside world has to your OS and application and ansure that all components that do access the outside world are up-to-date (curl is one of those libraries which would communicate to the outside world). So firewalling, OS updates, decent bit lenghs on your encryption keys, etc. Then you ensure all your applications are sandboxed so even if they are exploited the scope of data they can do is limited. But as you said, a sufficiently competent and determined hacker will likely find a way into many a "secure" system. But if you can limit the code that is exposed to the internet then you at least limit the amount of code that can be exploited (or rather force an attacker to use more than one attack in conjunction to gain system access). However if an attacker has physical access to your system then I'd just give up now as you've already lost.

tptacek 10y ago

There's pretty much no good reason that the most widely used command line HTTP fetcher should be a giant C project.

rini17 10y ago
For libcurl - easy linking to any C/C++ code is very good reason. And standalone curl is lighweight with minimal system dependencies.
- tptacek 10y ago
  I understand libcurl well (I've used it before on projects), and don't dispute its utility. I also understand the value of a very small C-based HTTP fetcher for system bootstrapping (I'm not sure that's really what curl is). What I don't get is why the most widely used general purpose command line HTTP fetcher is a giant C program that we're still finding UAFs in in 2016. I respect the enormous effort that goes into maintaining curl (though I have my differences with the way security is handled). But it's past time curl is replaced by a Rust or Go program.
  - tomcam 10y ago
    You're a pretty smart guy. Why not just knock out that little baby yourself?
    - tptacek 10y ago
      I'm hoping someone else already is.
      - JoachimSchipper 10y ago
        You might want to consider OpenBSD's ftp. It does a lot more than FTP.
  - shakna 10y ago
    A statically linked curl for ARM64 is 205kb. A statically linked hello world in Rust for ARM64 is 680kb. Curl is used for a ton of embedded hardware, and is probably in your router. Until Rust can solve its massive binaries, that is somewhere on their roadmap, it just isn't appropriate for use in the embedded world, where kilobytes still count.