13 ms·

Pretty much. The best way to insert supply chain exploits is to embed them in a stack exchange answer to a beginner's question. This isn't new, we've always ha

Pretty much. The best way to insert supply chain exploits is to embed them in a stack exchange answer to a beginner's question. This isn't new, we've always had programmers who programmed by "recipe" rather than first principles, and DRY paints that as a feature, but it underlies a lot of pain and cost over the years. To give some context, I inherited some kernel code when I worked in the Systems Group at Sun Microsystems in the 80's that was written by a mathematician who had become a programmer because the money was in programming, not applied math. They had cut and pasted code they didn't understand in order to achieve the result they wanted out of the code they were "writing." When I inherited it I read through it and found a couple of dozen ways the code would panic the kernel[1]. Once fixing those obvious issues, it became clear that the original owner of the code didn't really understand what computation did. They had an idea, and mathematically they could show that it was correct, but literally no ability to express that algorithmically. This is not a "new" problem but it is an important one that managers of software engineers need to watch for. [1] At the time the only difference between "kernel" programmers and "application" programmers was that kernel programmers recognized that unsafe code crashed the whole system, not just the application. So they tended to be cultivated from paranoid programmers.

pvg 5y ago
The best way to insert supply chain exploits is to embed them in a stack exchange answer to a beginner's question. None of these answers seem to come from SE so this might be harder than you might assume.
- Godel_unicode 5y ago
  It's not. Note that these threads are a few years old, but in recent research (stay tuned!) it has if anything gotten worse. https://news.ycombinator.com/item?id=13099690 https://news.ycombinator.com/item?id=13099690 https://laurent22.github.io/so-injections/ https://laurent22.github.io/so-injections/
  - pvg 5y ago
    It may have but this research doesn't show that. It appears to be in questions, rather than answers, when I can find a page that hasn't been removed. Beside most of these not actually being there, the google result is for answers which additionally have been ranked by Google. The thing you link is not meaningfully comparable to the Google result, nor is it representative of 'if you search for something on SE, how often does it tell you to put SQLI in your code'.
latchkey 5y ago
> The best way to insert supply chain exploits is to embed them in a stack exchange answer to a beginner's question. I'd love to see a concrete example of this happening in this way! The rest of your story just describes 'smart, but bad jr. programmer' and doesn't really discuss the exploit issue.
treeman79 5y ago
Thought the best way was to develop a basic and easy library. Then upload a malicious binary that doesn’t match the source. There was a really good post on how to do it and evade detection.
kadoban 5y ago
In PHP's case, Stack Exchange is not necessary to get SQL injected tutorials. The official docs for _years_, if not decades, included them. The docs for how you were supposed to do SQL were just full of the antipattern of building queries by string formatting and concatenation. I wouldn't be surprised if some dark corner of the docs still had those available.
- nine_k 5y ago
  "Else you are not getting the authentic php4 experience!" /s PHP has been in a poor shape for many, many years. It started shaping up in last rather few years, and there is a large backlog to tackle, colossal if you include all the numerous tutorials and Q&As from getting copy-pasted since 2000.
  - mschuster91 5y ago
    The language never was the problem, not since PHP 5.1 at least (which introduced PDO) and that is 16 years ago. The problem always was the ecosystem that took decades to update and the fact that Google's search is algorithm-ranked and not supposed to be curated by humans, which would have kicked out at least the most horribly insecure stuff.
    - jeltz 5y ago
      I disagree. As someone who has used PDO a lot it still makes it unnecessarily hard to use parametrized queries compared to the libraries available in most other languages, even C (at least for PostgreSQL). The pgsql library for PHP is also pretty good, better than PDO.
      - habibur 5y ago
        But, you need to write the hard thing once. In a 10 line wrapper function and then call that function from everywhere. sql_query($db,$sql,$params); Problem solved. I guess every PHP developer writes a bunch of these wrapper functions for common sql tasks before he starts his work.
simion314 5y ago
The problem seems to me to be if you hire newb developers and don't have any mentor-ship or code review. Any non-newb dev will know that you ALWAYS have to sanitize strings for SQL. file names or whatever. Most SQL ORMs or libraries will let the developer run raw SQL so you better have some competent person writing teh code or at least review it.
- acdha 5y ago
  > Any non-newb dev will know that you ALWAYS have to sanitize strings for SQL. file names or whatever. This is the “No true Scotsman” fallacy of programming. There are many people with plenty of experience who haven’t yet learned that lesson memorably and at least an order of magnitude more who know it but don’t exhaustively trace every data flow through the system and assume something already handled validation or escaping, being correct all but a fatal few times. With unsafe defaults an attacker only has to find a mistake once — you have to find them all.
  - simion314 5y ago
    There is no unsafe defaults, all ORMs allow you to run raw SQL so same "newb dev" can do same stupid thing if it finds a SQL tutorial when googling "how to do X". You need to teach developers to always escape strings, even if we remove old and bad tutorials you still need to teach the devs about this issues, otherwise they will do the mistake with file names, or with parameters to shell commands. It might mean having to read a book and not reeling on Google and soon on AI to teach you to code or SQL.
    - acdha 5y ago
      There’s a difference between what you encourage and what’s technically possible. PHP code so commonly has bugs of this class because there’s a quarter century of tradition, examples, and tutorials normalizing the idea of taking request variables and passing them directly to other code. Contrast with something like the Django tutorials & docs where the examples pervasively use the ORM’s escaping & validation and the extension points describing how to use custom SQL tell you to use placeholders and emphasize why it’s important. That might not seem like a lot at first thought but it lowers the bug frequency enormously in the code I’ve looked at because you only need extreme caution in rare cases rather than every view. That means that when someone is busy, having a bad day, etc. they either have no problem or it’s a safe crash rather than an exploitable hole.
gjs278 5y ago
nobody is intentionally inserting bad code on answers. they are just bad programmers giving what they think is helpful advice.
dylan604 5y ago
In 1980s, where did one go to find code to copy&paste?
- jimmygrapes 5y ago
  Mailing lists and USENET mostly, with FTP listing of open source code here and there, followed by transcribing from printed material
- fencepost 5y ago
  Dr. Dobb's Journal of Computer Calisthenics & Orthodontia Running Light without Overbyte
- dataviz1000 5y ago
  copy & paste ... ha I wish. We had to type it bit by bit from the back of a magazine back in my day. Do you remember this? [0] [0] https://arstechnica.com/staff/2018/11/first-encounter-compute-magazine-and-its-glorious-tedious-type-in-code/ https://arstechnica.com/staff/2018/11/first-encounter-comput...
  - dylan604 5y ago
    This is exactly how I got into coding. A friend had the computer, and the 2 of us would hunt&peck the code in. We were maybe 12 years old. The DATA lines were the tricky spots. Everything else used words we could understand, and it just made sense after doing it enough. The DATA was just jibberish. We found it easiest if one typed while the other called out the data. Faster and fewer mistakes.
    - jonwinstanley 5y ago
      Same. I used to buy Amiga Format magazine for the game reviews then found the code for creating my own game was way more fun
- jussij 5y ago
  Back in the late 80s and early 90s many people learned to code from a book. You would just study the code samples found in those books.
p1necone 5y ago
> DRY paints that as a feature That's not what DRY should be. Good developers should understand at least a couple of levels of abstraction underneath what they're writing in order to produce sensible code. The idea of abstraction is that you only have to spend the afternoon/day/week (depending on the complexity that's being abstracted over) learning how everything comes together once, as opposed to spending that time to grok a slightly different version of the same complex system every time you read/write something new.
- ahmedalsudani 5y ago
  Yeah; anyone who thinks DRY means copy the answer on SO is completely missing the point. DRY should not introduce vulnerabilities. It avoids them by 1. reducing complexity and cognitive overhead 2. allowing you to fix your code in one place and propagate your fix throughout the codebase
tshaddox 5y ago
> This isn't new, we've always had programmers who programmed by "recipe" rather than first principles, and DRY paints that as a feature, but it underlies a lot of pain and cost over the years. Something tells me that exploiters love the programmers who attempt to build user authentication systems from first principles.
ericye16 5y ago
"Programming from first principles" doesn't solve security problems, in fact security problems in this case come from being ignorant of best practices and industry experiences. You would _want_ programmers to use established techniques to avoid this problem. Of course developers should always understand what their code is doing though.
crazygringo 5y ago
> The best way to insert supply chain exploits is to embed them in a stack exchange answer to a beginner's question. Do you have any actual evidence for that? As Hanlon says, "never ascribe to malice that which is adequately explained by incompetence." Incompetence explains this one fully for me.
- eyelidlessness 5y ago
  It doesn't take a malicious actor to make a honeypot, only to exploit it. If someone naively posts a widely used solution on a help site, they've done the job for the exploiter, who only needs to know what low hanging vulnerability fruit awaits them.
dragonwriter 5y ago
> This isn't new, we've always had programmers who programmed by "recipe" rather than first principles, and DRY paints that as a feature No, it doesn't. Programming by recipe rather than building the recipe into a reusable abstraction is the exact opposite of DRY.
p5a0u9l 5y ago
Ironic how in today's market the applied math dude could easily transition into some higher paying role like ML Engineer or Data Scientist. Not knocking those roles by any means, but the tech world seems ravenous for algorithms. From my experience, algorithms are easy and the software engineering is hard. What’s more, many, not all, but many of these algorithm scientists look down on their programmer counterparts. It’s these folks who end up making the algorithm successful for the company.
raxxorrax 5y ago
I believe all programmers will resort to copying code without too much of a review at some point. Strict first principles would mean not to rely on mental work of predecessors, which is entirely unrealistic today. Maybe that could work in the 80s, but the amount of software layers today is astonishing. I develop bare metal code for special µC, but I would never imagine to build even a basic OS. This is work you spend your lifetime in. Of course if I could just copy the things from established OS things might look differently. That said, I don't think the first steps in SQL should guard against SQL injection. That is a topic for later and only hides the main learning target. You can understand SQL perfectly by first principles and still cause your first program to allow for such injection. But that should be a different lesson at first. Being able to identify it as a danger also relies on the experience of others.

pvg 5y ago

The best way to insert supply chain exploits is to embed them in a stack exchange answer to a beginner's question. None of these answers seem to come from SE so this might be harder than you might assume.

Godel_unicode 5y ago
It's not. Note that these threads are a few years old, but in recent research (stay tuned!) it has if anything gotten worse. https://news.ycombinator.com/item?id=13099690 https://news.ycombinator.com/item?id=13099690 https://laurent22.github.io/so-injections/ https://laurent22.github.io/so-injections/
- pvg 5y ago
  It may have but this research doesn't show that. It appears to be in questions, rather than answers, when I can find a page that hasn't been removed. Beside most of these not actually being there, the google result is for answers which additionally have been ranked by Google. The thing you link is not meaningfully comparable to the Google result, nor is it representative of 'if you search for something on SE, how often does it tell you to put SQLI in your code'.

latchkey 5y ago

> The best way to insert supply chain exploits is to embed them in a stack exchange answer to a beginner's question. I'd love to see a concrete example of this happening in this way! The rest of your story just describes 'smart, but bad jr. programmer' and doesn't really discuss the exploit issue.

treeman79 5y ago

Thought the best way was to develop a basic and easy library. Then upload a malicious binary that doesn’t match the source. There was a really good post on how to do it and evade detection.

kadoban 5y ago

In PHP's case, Stack Exchange is not necessary to get SQL injected tutorials. The official docs for _years_, if not decades, included them. The docs for how you were supposed to do SQL were just full of the antipattern of building queries by string formatting and concatenation. I wouldn't be surprised if some dark corner of the docs still had those available.

nine_k 5y ago
"Else you are not getting the authentic php4 experience!" /s PHP has been in a poor shape for many, many years. It started shaping up in last rather few years, and there is a large backlog to tackle, colossal if you include all the numerous tutorials and Q&As from getting copy-pasted since 2000.
- mschuster91 5y ago
  The language never was the problem, not since PHP 5.1 at least (which introduced PDO) and that is 16 years ago. The problem always was the ecosystem that took decades to update and the fact that Google's search is algorithm-ranked and not supposed to be curated by humans, which would have kicked out at least the most horribly insecure stuff.
  - jeltz 5y ago
    I disagree. As someone who has used PDO a lot it still makes it unnecessarily hard to use parametrized queries compared to the libraries available in most other languages, even C (at least for PostgreSQL). The pgsql library for PHP is also pretty good, better than PDO.
    - habibur 5y ago
      But, you need to write the hard thing once. In a 10 line wrapper function and then call that function from everywhere. sql_query($db,$sql,$params); Problem solved. I guess every PHP developer writes a bunch of these wrapper functions for common sql tasks before he starts his work.

simion314 5y ago

The problem seems to me to be if you hire newb developers and don't have any mentor-ship or code review. Any non-newb dev will know that you ALWAYS have to sanitize strings for SQL. file names or whatever. Most SQL ORMs or libraries will let the developer run raw SQL so you better have some competent person writing teh code or at least review it.

acdha 5y ago
> Any non-newb dev will know that you ALWAYS have to sanitize strings for SQL. file names or whatever. This is the “No true Scotsman” fallacy of programming. There are many people with plenty of experience who haven’t yet learned that lesson memorably and at least an order of magnitude more who know it but don’t exhaustively trace every data flow through the system and assume something already handled validation or escaping, being correct all but a fatal few times. With unsafe defaults an attacker only has to find a mistake once — you have to find them all.
- simion314 5y ago
  There is no unsafe defaults, all ORMs allow you to run raw SQL so same "newb dev" can do same stupid thing if it finds a SQL tutorial when googling "how to do X". You need to teach developers to always escape strings, even if we remove old and bad tutorials you still need to teach the devs about this issues, otherwise they will do the mistake with file names, or with parameters to shell commands. It might mean having to read a book and not reeling on Google and soon on AI to teach you to code or SQL.
  - acdha 5y ago
    There’s a difference between what you encourage and what’s technically possible. PHP code so commonly has bugs of this class because there’s a quarter century of tradition, examples, and tutorials normalizing the idea of taking request variables and passing them directly to other code. Contrast with something like the Django tutorials & docs where the examples pervasively use the ORM’s escaping & validation and the extension points describing how to use custom SQL tell you to use placeholders and emphasize why it’s important. That might not seem like a lot at first thought but it lowers the bug frequency enormously in the code I’ve looked at because you only need extreme caution in rare cases rather than every view. That means that when someone is busy, having a bad day, etc. they either have no problem or it’s a safe crash rather than an exploitable hole.

gjs278 5y ago

nobody is intentionally inserting bad code on answers. they are just bad programmers giving what they think is helpful advice.

dylan604 5y ago

In 1980s, where did one go to find code to copy&paste?

jimmygrapes 5y ago
Mailing lists and USENET mostly, with FTP listing of open source code here and there, followed by transcribing from printed material
fencepost 5y ago
Dr. Dobb's Journal of Computer Calisthenics & Orthodontia Running Light without Overbyte
dataviz1000 5y ago
copy & paste ... ha I wish. We had to type it bit by bit from the back of a magazine back in my day. Do you remember this? [0] [0] https://arstechnica.com/staff/2018/11/first-encounter-compute-magazine-and-its-glorious-tedious-type-in-code/ https://arstechnica.com/staff/2018/11/first-encounter-comput...
- dylan604 5y ago
  This is exactly how I got into coding. A friend had the computer, and the 2 of us would hunt&peck the code in. We were maybe 12 years old. The DATA lines were the tricky spots. Everything else used words we could understand, and it just made sense after doing it enough. The DATA was just jibberish. We found it easiest if one typed while the other called out the data. Faster and fewer mistakes.
  - jonwinstanley 5y ago
    Same. I used to buy Amiga Format magazine for the game reviews then found the code for creating my own game was way more fun
jussij 5y ago
Back in the late 80s and early 90s many people learned to code from a book. You would just study the code samples found in those books.

p1necone 5y ago

> DRY paints that as a feature That's not what DRY should be. Good developers should understand at least a couple of levels of abstraction underneath what they're writing in order to produce sensible code. The idea of abstraction is that you only have to spend the afternoon/day/week (depending on the complexity that's being abstracted over) learning how everything comes together once, as opposed to spending that time to grok a slightly different version of the same complex system every time you read/write something new.

ahmedalsudani 5y ago
Yeah; anyone who thinks DRY means copy the answer on SO is completely missing the point. DRY should not introduce vulnerabilities. It avoids them by 1. reducing complexity and cognitive overhead 2. allowing you to fix your code in one place and propagate your fix throughout the codebase

tshaddox 5y ago

> This isn't new, we've always had programmers who programmed by "recipe" rather than first principles, and DRY paints that as a feature, but it underlies a lot of pain and cost over the years. Something tells me that exploiters love the programmers who attempt to build user authentication systems from first principles.

ericye16 5y ago

"Programming from first principles" doesn't solve security problems, in fact security problems in this case come from being ignorant of best practices and industry experiences. You would _want_ programmers to use established techniques to avoid this problem. Of course developers should always understand what their code is doing though.

crazygringo 5y ago

> The best way to insert supply chain exploits is to embed them in a stack exchange answer to a beginner's question. Do you have any actual evidence for that? As Hanlon says, "never ascribe to malice that which is adequately explained by incompetence." Incompetence explains this one fully for me.

eyelidlessness 5y ago
It doesn't take a malicious actor to make a honeypot, only to exploit it. If someone naively posts a widely used solution on a help site, they've done the job for the exploiter, who only needs to know what low hanging vulnerability fruit awaits them.

dragonwriter 5y ago

> This isn't new, we've always had programmers who programmed by "recipe" rather than first principles, and DRY paints that as a feature No, it doesn't. Programming by recipe rather than building the recipe into a reusable abstraction is the exact opposite of DRY.

p5a0u9l 5y ago

Ironic how in today's market the applied math dude could easily transition into some higher paying role like ML Engineer or Data Scientist. Not knocking those roles by any means, but the tech world seems ravenous for algorithms. From my experience, algorithms are easy and the software engineering is hard. What’s more, many, not all, but many of these algorithm scientists look down on their programmer counterparts. It’s these folks who end up making the algorithm successful for the company.

raxxorrax 5y ago

I believe all programmers will resort to copying code without too much of a review at some point. Strict first principles would mean not to rely on mental work of predecessors, which is entirely unrealistic today. Maybe that could work in the 80s, but the amount of software layers today is astonishing. I develop bare metal code for special µC, but I would never imagine to build even a basic OS. This is work you spend your lifetime in. Of course if I could just copy the things from established OS things might look differently. That said, I don't think the first steps in SQL should guard against SQL injection. That is a topic for later and only hides the main learning target. You can understand SQL perfectly by first principles and still cause your first program to allow for such injection. But that should be a different lesson at first. Being able to identify it as a danger also relies on the experience of others.