5 ms·

That's 6 CVEs against an obscure C networking library that I wrote. Technically, none of them were found in my code (not yet). All were in the third-party XML p

by Annatar 10y ago

That's 6 CVEs against an obscure C networking library that I wrote. Technically, none of them were found in my code (not yet). All were in the third-party XML parser that I chose to use. But that doesn't absolve me of fault, and I bet there's a few more bugs lurking in my code that could be found with modern fuzzers. While it is commendable that you take responsibility, you mis-diagnosed your error: it isn't the C programming language, but what you chose to do with it: send/receive extensible markup language for remote procedure calls. Seems like a great idea, until you actually have to deal with it. I just happen to be working on an application where I'm forced to generate XML-SOAP and send that over the network to a server, and then process the XML-SOAP response I get back with XPATH, using xsltproc. And all that because the designers of the server application use Java and didn't even know they were using XML-SOAP and XPATH, since by the time they work with it, Java libraries treat them as objects. (And neither did I, until I reverse-engineered the responses I'm getting.) I have caused the server to crash innumerable amount of times. You're arguing for better systems languages, and I'm telling you that is a terrible idea because we have nobody so smart as to design something so complex to be simple, and the closest we have ever come to it is C. We already have way too many languages, that it's become a nauseating torture to work with computers.

pka 10y ago
So you're saying C is a great language until you have to parse XML. ... exactly.
- Annatar 10y ago
  That is exactly what I am saying, and more: - don't use XML for anything; - use the correct tool for the job, but first define the problem better. What was XML-RPC attempting to solve?
  - pka 10y ago
    You're making a great point against C, yet somehow you are not realizing it.
    - abritinthebay 10y ago
      You're right, but I think he's also making a wider argument that C isn't good at fixing bad application or data design choices choices for you. He considers that a positive feature, not a bad thing. You're the inverse. I can see both sides of that tbh. It's a justifiable - but myopically idealistic - point. But man he's being a pretentious ass about it.
      - pka 10y ago
        I can't see how this can be a good thing. If C is that bad at managing complexity (and complexity doesn't only arise from bad design choices, some problems are inherently complex) then it should be used as rarely as possible, period. It's not about idealism, it's about ill-placed, almost comical elitism ("C is a low-level-hacker language and only real programmers use it" while a 3rd grader could understand pointer arithmetic) to the point of rather spending 5 days writing bug-ridden code in C instead of 5 minutes in whatever else, just because it's the right way. It's ridiculous.
        moosingin3space 10y ago
        > If C is that bad at managing complexity This, in my opinion, is why even if C were somehow free of buffer/integer overflow, UAF, and other vulnerabilities, it would still be a poor choice for many real-world (read: complex) applications.
        Pica_soO 10y ago
        You can always glue stuff to the compiler and reinvent c++.
      - Annatar 10y ago
        You're right, but I think he's also making a wider argument that C isn't good at fixing bad application or data design choices choices for you. Bingo, give the man a prize! As we say on UNIX: C gives one enough rope to hang oneself. It is expected one knows what one is doing, but in return, one gets complete control and infinite flexibility. No programming language can compensate for bad architectural decisions, or an absence of such decisions, or absence of insight. Such a programming language does not yet exist, and it is questionable whether it ever will. So yeah, you got exactly what I was trying to say. Now, back to C: nobody, including me, has all the solutions, but from experience, I have some tips when writing C code: run the damn thing you're building through a debugger; feed it all kinds of garbage while doing so; try to break it in every way, shape, or form you can think of. As the author of the program, one should have unique and powerful insights into where the weak points are. And after all of that is done and fixed, have someone completely unrelated to it try to break it. This last piece of advice is good for any language. I have a friend. I'd beat the daylights out of my programs, break them every which way, fix all the bugs I could find, then I'd let him have at it. He'd usually break my program in 15 - 25 seconds. Then the cycle would repeat, until he could no longer break anything. At that point, we had something remotely resembling stable software. And a lot of those programs I had him break weren't even written in C! One of the best techniques I found while developing in both assembler and C: run the program you're working on through the debugger as you're writing it. As soon as I write a new function, I fire up a debugger (or shell tracing, or...) One wouldn't believe how many bugs I've found and fixed before the program saw the light of day. And it saves so much time, even though that's completely counter-intuitive.
  - ekidd 10y ago
    What was XML-RPC attempting to solve? That's an excellent question! To answer it, we need to rewind to the year 1998. Nobody had ever heard of JSON (2002) or REST (2000) or SOAP. If you wanted to do remote procedure calls, you needed to use Sun RPC or Corba or another binary RPC stack. Some of these required tens of thousands of lines of C code to implement, and I don't even want to think about the security issues. Basically, XML-RPC was trying to be REST+JSON before that was a thing. It had already been implemented for most scripting languages, but one of my consulting clients needed a C implementation to interoperate, so I wrote xmlrpc-c in a couple of busy weeks around the end of 2000, I think. Back in those days, XML had a very clear 30 page spec and XML-RPC had a 2 page spec. If you want to argue that I was wrong to use C to implement 32 pages of pretty good specs, or that I was wrong to use the best off-the-shelf XML parser of the day, well, I agree. But I think we need to demand more from our system languages.
    - pjc50 10y ago
      I think one could actually argue that all RPC protocols have ended in unmanageable disaster, and that the only things that endure are IETF-style protocol-first human-readable systems. However, that would take a lot of argument which I'm not committed to.
    - kabdib 10y ago
      I looked at XML-RPC when it came out, and knew instantly that it would be a disaster. Even when you took out the XML-ness, the underlying concepts were complicated, badly explained and open to a ton of wiggle room. Then you add the inefficiencies of XML encoding, and the utterly crappy nature of most XML translation layers . . . yeah, really easy to see the train wreck coming.
      - deleted 10y ago
        [deleted]
      - plywoodtrees 10y ago
        Sure, XML-RPC not the best protocol. Compared to others it's pretty simple, and the mess and number of edge cases is smaller than SSL or TCP/IP. If C isn't up to implementing an only slightly complicated network protocol, it's not much of a systems programming language, is it? It turns out, C is fine for writing such systems and getting them working fairly well, but very poor at making them really reliable and secure, and that's no longer a good tradeoff.
  - RUG3Y 10y ago
    "don't use XML for anything" This just made me laugh. I'm not making a value judgement about your statement, I neither agree nor disagree.
Retra 10y ago
What's the ideal number of languages, in your opinion, and in what year do you imaging we passed that number? There were "too many languages" before C was even conceived of. If that were a reason to not use new languages, you'd never even have heard of C.
- Annatar 10y ago
  Five. We passed that way back in the '60's of the past century. Any more than five becomes counterproductive and destructive, because it's physically impossible to keep up with all of the new languages coming out, and no language solves all the problems simply and efficiently. Or elegantly, for that matter. In my experience, it takes about ten years of heavy use to master a programming language and use it not only to its fullest extent, but correctly and efficiently as well. I would be interested to meet a person who has that kind of time, biologically. If that were a reason to not use new languages, you'd never even have heard of C. Back in my day, the number of computer platforms was pragmatically limited: either you wrote software for the Commodore Amiga, or you wrote software for the Atari ST. If you were a software company, you wrote for both. If you were a programmer with lots of experience, you split the core from the hardware dependent subroutines, but I don't think anyone thought about this very UNIX-specific approach to programming back then (most of us had never heard of UNIX). We all wrote software in assembler, and were just lucky enough that both major platforms had the exact same processor family, the Motorola 68000. The C programming language was a solution to a problem nobody had or asked for. I remember making fun of my mathematics teacher and berating him for writing programs in C, because compared to assembler, it was lame: bloated and slow. It was impossible to code something of any significant speed and small enough size in C on either Atari ST or the Amiga. We viewed C as something lamers who couldn't figure out assembler dabbled with. One just couldn't compete in C with code written in assembler, which effectively meant that if you didn't code in assembler, and your code wasn't small or fast enough, or both, you weren't competitive, and the lamer label was soon to follow. Times have changed, C is now the portable assembler, but they have changed only somewhat. When push comes to shove, understanding what happens at the hardware level is still crucial when performance problems strike... and they strike a lot. Most importantly, understanding how the hardware functions at the lowest level is most important when writing in really high level languages. The higher the language abstractions, more crucial understanding of how low level hardware functions becomes. Nowadays, when I have multple incompatible processors to deal with, completely different hardware architectures, and plenty of raw processing power, C is a very viable, even desirable choice: if I write my code cleanly enough, it will just compile and run everywhere without modification, and I'm done, but back then... ...C was the answer to a question nobody asked or cared for in the personal / home computer space in those days. If one couldn't figure out assembler, one dabbled in GFA-BASIC or C, or Pascal. It was a very elitist, eat or be eaten environment. If one's code was too large or too slow, one became the public laughing stock of the scene. It was a very effective, and highly motivating selection measure. I miss those days.
xenadu02 10y ago
I'm gonna go out on a limb here and say you've shipped numerous RCEs and don't even know it.

by Annatar 10y ago

pka 10y ago

So you're saying C is a great language until you have to parse XML. ... exactly.

Annatar 10y ago
That is exactly what I am saying, and more: - don't use XML for anything; - use the correct tool for the job, but first define the problem better. What was XML-RPC attempting to solve?
- pka 10y ago
  You're making a great point against C, yet somehow you are not realizing it.
  - abritinthebay 10y ago
    You're right, but I think he's also making a wider argument that C isn't good at fixing bad application or data design choices choices for you. He considers that a positive feature, not a bad thing. You're the inverse. I can see both sides of that tbh. It's a justifiable - but myopically idealistic - point. But man he's being a pretentious ass about it.
    - pka 10y ago
      I can't see how this can be a good thing. If C is that bad at managing complexity (and complexity doesn't only arise from bad design choices, some problems are inherently complex) then it should be used as rarely as possible, period. It's not about idealism, it's about ill-placed, almost comical elitism ("C is a low-level-hacker language and only real programmers use it" while a 3rd grader could understand pointer arithmetic) to the point of rather spending 5 days writing bug-ridden code in C instead of 5 minutes in whatever else, just because it's the right way. It's ridiculous.
      - moosingin3space 10y ago
        > If C is that bad at managing complexity This, in my opinion, is why even if C were somehow free of buffer/integer overflow, UAF, and other vulnerabilities, it would still be a poor choice for many real-world (read: complex) applications.
        Pica_soO 10y ago
        You can always glue stuff to the compiler and reinvent c++.
    - Annatar 10y ago
      You're right, but I think he's also making a wider argument that C isn't good at fixing bad application or data design choices choices for you. Bingo, give the man a prize! As we say on UNIX: C gives one enough rope to hang oneself. It is expected one knows what one is doing, but in return, one gets complete control and infinite flexibility. No programming language can compensate for bad architectural decisions, or an absence of such decisions, or absence of insight. Such a programming language does not yet exist, and it is questionable whether it ever will. So yeah, you got exactly what I was trying to say. Now, back to C: nobody, including me, has all the solutions, but from experience, I have some tips when writing C code: run the damn thing you're building through a debugger; feed it all kinds of garbage while doing so; try to break it in every way, shape, or form you can think of. As the author of the program, one should have unique and powerful insights into where the weak points are. And after all of that is done and fixed, have someone completely unrelated to it try to break it. This last piece of advice is good for any language. I have a friend. I'd beat the daylights out of my programs, break them every which way, fix all the bugs I could find, then I'd let him have at it. He'd usually break my program in 15 - 25 seconds. Then the cycle would repeat, until he could no longer break anything. At that point, we had something remotely resembling stable software. And a lot of those programs I had him break weren't even written in C! One of the best techniques I found while developing in both assembler and C: run the program you're working on through the debugger as you're writing it. As soon as I write a new function, I fire up a debugger (or shell tracing, or...) One wouldn't believe how many bugs I've found and fixed before the program saw the light of day. And it saves so much time, even though that's completely counter-intuitive.
- ekidd 10y ago
  What was XML-RPC attempting to solve? That's an excellent question! To answer it, we need to rewind to the year 1998. Nobody had ever heard of JSON (2002) or REST (2000) or SOAP. If you wanted to do remote procedure calls, you needed to use Sun RPC or Corba or another binary RPC stack. Some of these required tens of thousands of lines of C code to implement, and I don't even want to think about the security issues. Basically, XML-RPC was trying to be REST+JSON before that was a thing. It had already been implemented for most scripting languages, but one of my consulting clients needed a C implementation to interoperate, so I wrote xmlrpc-c in a couple of busy weeks around the end of 2000, I think. Back in those days, XML had a very clear 30 page spec and XML-RPC had a 2 page spec. If you want to argue that I was wrong to use C to implement 32 pages of pretty good specs, or that I was wrong to use the best off-the-shelf XML parser of the day, well, I agree. But I think we need to demand more from our system languages.
  - pjc50 10y ago
    I think one could actually argue that all RPC protocols have ended in unmanageable disaster, and that the only things that endure are IETF-style protocol-first human-readable systems. However, that would take a lot of argument which I'm not committed to.
  - kabdib 10y ago
    I looked at XML-RPC when it came out, and knew instantly that it would be a disaster. Even when you took out the XML-ness, the underlying concepts were complicated, badly explained and open to a ton of wiggle room. Then you add the inefficiencies of XML encoding, and the utterly crappy nature of most XML translation layers . . . yeah, really easy to see the train wreck coming.
    - deleted 10y ago
      [deleted]
    - plywoodtrees 10y ago
      Sure, XML-RPC not the best protocol. Compared to others it's pretty simple, and the mess and number of edge cases is smaller than SSL or TCP/IP. If C isn't up to implementing an only slightly complicated network protocol, it's not much of a systems programming language, is it? It turns out, C is fine for writing such systems and getting them working fairly well, but very poor at making them really reliable and secure, and that's no longer a good tradeoff.
- RUG3Y 10y ago
  "don't use XML for anything" This just made me laugh. I'm not making a value judgement about your statement, I neither agree nor disagree.

Retra 10y ago

What's the ideal number of languages, in your opinion, and in what year do you imaging we passed that number? There were "too many languages" before C was even conceived of. If that were a reason to not use new languages, you'd never even have heard of C.

Annatar 10y ago
Five. We passed that way back in the '60's of the past century. Any more than five becomes counterproductive and destructive, because it's physically impossible to keep up with all of the new languages coming out, and no language solves all the problems simply and efficiently. Or elegantly, for that matter. In my experience, it takes about ten years of heavy use to master a programming language and use it not only to its fullest extent, but correctly and efficiently as well. I would be interested to meet a person who has that kind of time, biologically. If that were a reason to not use new languages, you'd never even have heard of C. Back in my day, the number of computer platforms was pragmatically limited: either you wrote software for the Commodore Amiga, or you wrote software for the Atari ST. If you were a software company, you wrote for both. If you were a programmer with lots of experience, you split the core from the hardware dependent subroutines, but I don't think anyone thought about this very UNIX-specific approach to programming back then (most of us had never heard of UNIX). We all wrote software in assembler, and were just lucky enough that both major platforms had the exact same processor family, the Motorola 68000. The C programming language was a solution to a problem nobody had or asked for. I remember making fun of my mathematics teacher and berating him for writing programs in C, because compared to assembler, it was lame: bloated and slow. It was impossible to code something of any significant speed and small enough size in C on either Atari ST or the Amiga. We viewed C as something lamers who couldn't figure out assembler dabbled with. One just couldn't compete in C with code written in assembler, which effectively meant that if you didn't code in assembler, and your code wasn't small or fast enough, or both, you weren't competitive, and the lamer label was soon to follow. Times have changed, C is now the portable assembler, but they have changed only somewhat. When push comes to shove, understanding what happens at the hardware level is still crucial when performance problems strike... and they strike a lot. Most importantly, understanding how the hardware functions at the lowest level is most important when writing in really high level languages. The higher the language abstractions, more crucial understanding of how low level hardware functions becomes. Nowadays, when I have multple incompatible processors to deal with, completely different hardware architectures, and plenty of raw processing power, C is a very viable, even desirable choice: if I write my code cleanly enough, it will just compile and run everywhere without modification, and I'm done, but back then... ...C was the answer to a question nobody asked or cared for in the personal / home computer space in those days. If one couldn't figure out assembler, one dabbled in GFA-BASIC or C, or Pascal. It was a very elitist, eat or be eaten environment. If one's code was too large or too slow, one became the public laughing stock of the scene. It was a very effective, and highly motivating selection measure. I miss those days.

xenadu02 10y ago

I'm gonna go out on a limb here and say you've shipped numerous RCEs and don't even know it.