Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hidden Messages in Emojis and Hacking the US Treasury

slamdunksoftware.substack.com

Post reply on HN
Print view View original

71–80 of 82 posts

Re: Hidden Messages in Emojis and Hacking the US Treasury

#71

Post by [deleted] »

gcr wrote: post #68
cogman10 wrote: post #28

Earlier quoted context omitted.

> They sanitized the data, so it should have been fine. This is a 101 rookie level approach to SQL or injection defense. It's dumb for exactly the same reason why this is dumb "SELECT * FROM foo WHERE bar=" + sanitize(userInput) The correct way to do something like this will always be parameterized input which looks something like this "SELECT * FROM foo WHERE bar=?" bindParameter(1, userInput); Why? Because that the…

I’m starting to think that string-based languages like SQL which mix structure and content are a mistake. Maybe future database systems will only accept queries serialized from protobuf, or JSON (output by a proper serializer)

[deleted]

Re: Hidden Messages in Emojis and Hacking the US Treasury

#73

Post by Validark »

whatnow37373 wrote: post #62
Validark wrote: post #61

Earlier quoted context omitted.

To me, "sanitizing inputs" implies a transformation of the data into a string that can be "safely" evaluated as code which hopefully yields the input data. Instead you should be able to just mark a piece of the code as data, that will never be tokenized or parsed or anything, just dropped directly into a buffer. "Prepared statements" sounds EXACTLY like what I was thinking! I don't understand why people would ever us…

Ah, I see! It's a cool idea, but .. let's try to be maximally obtuse and pedantic today. I'm a developer and it's HN after all. [4]tree is also code that yields data. At the end of the day some kind of parser needs to decide what to do with your data and [ ] is just another way of escaping special characters. In this case it escapes entire strings instead of individual characters. It's your special way of sanitizing…

Yes, I almost certainly would write that wrapper to make it impossible for me to pair the wrong length with a string. And yes, it technically is still code, but at least the bytes are not being "looked at" in a way where they might get executed in some way. Again, a "Prepared Statement" is what I was hoping would exist (also for perf reasons) so I'm happy to know it does.

If I were writing it, I would exclusively use the "Prepared Statements" technique, and for people typing in SQL queries by hand, the sole string construct would be as I described.

I'm a Ziguana, so in my design, the number would be "bytes". You would have to "calculate" the number of bytes in languages like Swift or JavaScript. But still, overall it's a better idea to me than turning ' into \' and many other convoluted transformations that are often incorrect and are also just throwing away CPU cycles for no reason whatsoever.

In any case, I would still be semi-offended if I learned that "Prepared Statements" transformed the data in any way whatsoever. In the compromise solution where SQL has a string construct, I want the SQL tokenizer to do this:

  if (cur_token.kind == .data) {
    // copy data out
    @memcpy(
      some_buffer, 
      cur[0..cur_token.value]
    );
    // skip over the whole thing
    // before generating next token
    cur = cur[cur_token.value..];
  }
Even better if the data is not sent alongside code at all.

Re: Hidden Messages in Emojis and Hacking the US Treasury

#74

Post by thaumasiotes »

TheDong wrote: post #57
thaumasiotes wrote: post #50

Earlier quoted context omitted.

> The correct way to do something like this will always be parameterized input which looks something like this > Why? Because [] the postgres protocol splits out the command and the data for the command in a way that can't be injected. I'm not sure I'm comfortable with this. You can create a prepared statement and then pass user input to it as parameters, sure. https://www.postgresql.org/docs/17/sql-prepare.html But…

The postgres escape function actually worked fine before this "CVE". It was documented as escaping something for use as part of a postgres query. BeyondTrust used it as input to the 'psql' tool, which is an interactive tool you're not really supposed to programmatically invoke, and the documentation for the postgres escape function didn't say it escaped input for psql. Even though postgres was fine calling it a CVE a…

> The postgres escape function actually worked fine before this "CVE". It was documented as escaping something for use as part of a postgres query.

> BeyondTrust used it as input to the 'psql' tool, which is an interactive tool you're not really supposed to programmatically invoke, and the documentation for the postgres escape function didn't say it escaped input for psql.

But this is the documentation for psql:

> psql is a terminal-based front-end to PostgreSQL. It enables you to type in queries interactively, issue them to PostgreSQL, and see the query results. Alternatively, input can be from a file or from command line arguments. In addition, psql provides a number of meta-commands and various shell-like features to facilitate writing scripts and automating a wide variety of tasks.

We can learn two things from this:

1. You are definitely supposed to be able to invoke psql programmatically, or else the suggestion to "write scripts and automate a wide variety of tasks" would make no sense.

2. The input to psql is documented as a "query", and it seems fine to assume that a "query" for psql is the same thing as a "postgres query".

Re: Hidden Messages in Emojis and Hacking the US Treasury

#75

Post by D-Coder »

namaria wrote: post #59
oefrha wrote: post #42

Earlier quoted context omitted.

The more you work in software the more you should realize the developers writing security-critical software (in this case the one writing that sanitizer) are often/usually as clueless as you are. The solution? Hard to say.

I have had a developer look me dead in the eye and say "this is not a security concern, because I can't see how this can be exploited". Security by obscurity from self. It was very hard to explain to that person what was wrong with that line of reasoning.

> It was very hard to explain to that person what was wrong with that line of reasoning.

"So... you're the smartest person in the world?"

Re: Hidden Messages in Emojis and Hacking the US Treasury

#76

Post by lazide »

D-Coder wrote: post #75
namaria wrote: post #59

Earlier quoted context omitted.

I have had a developer look me dead in the eye and say "this is not a security concern, because I can't see how this can be exploited". Security by obscurity from self. It was very hard to explain to that person what was wrong with that line of reasoning.

> It was very hard to explain to that person what was wrong with that line of reasoning. "So... you're the smartest person in the world?"

It’s very hard to argue with someone who asserts ‘what I don’t know can’t hurt me’, because usually they’ll refuse to know anything that will hurt them. Like that there are things they don’t know, that can hurt them.

Re: Hidden Messages in Emojis and Hacking the US Treasury

#77

Post by immibis »

namaria wrote: post #59
oefrha wrote: post #42

Earlier quoted context omitted.

The more you work in software the more you should realize the developers writing security-critical software (in this case the one writing that sanitizer) are often/usually as clueless as you are. The solution? Hard to say.

I have had a developer look me dead in the eye and say "this is not a security concern, because I can't see how this can be exploited". Security by obscurity from self. It was very hard to explain to that person what was wrong with that line of reasoning.

But... You have to see things that way or else literally everything becomes a security concern.. Extra whitespace before a semicolon? I don't see how it can be exploited, but with the mindset you imply, I have to treat it as a security concern. But removing the whitespace is also a security concern.

Re: Hidden Messages in Emojis and Hacking the US Treasury

#78

Post by immibis »

gcr wrote: post #68
cogman10 wrote: post #28

Earlier quoted context omitted.

> They sanitized the data, so it should have been fine. This is a 101 rookie level approach to SQL or injection defense. It's dumb for exactly the same reason why this is dumb "SELECT * FROM foo WHERE bar=" + sanitize(userInput) The correct way to do something like this will always be parameterized input which looks something like this "SELECT * FROM foo WHERE bar=?" bindParameter(1, userInput); Why? Because that the…

I’m starting to think that string-based languages like SQL which mix structure and content are a mistake. Maybe future database systems will only accept queries serialized from protobuf, or JSON (output by a proper serializer)

JSON is a string-based language. So are Java, C, Rust, and so on.

Re: Hidden Messages in Emojis and Hacking the US Treasury

#79

Post by rapind »

hnlmorg wrote: post #52
rapind wrote: post #30

Earlier quoted context omitted.

> Unicode is a surprisingly elegant system… s/elegant/clever What could go wrong? I bet unicode is how AGI escapes and enslaves humanity.

The cleverness is in the simplicity of its implementation while maintaining backwards compatibility. Which satisfies the definition of “elegance”. Working with Unicode is anything but elegant, but that’s another story.

> Working with Unicode is anything but elegant, but that’s another story.

Yeah I hear ya. IMO this is really important though and I don’t think there’s much of a story if this isn’t part of it. The design is clever but the resulting usability (and error proneness) leaves much to be desired. Not knowing what’s in there, like a closed envelope, increases user complexity significantly.

Re: Hidden Messages in Emojis and Hacking the US Treasury

#80

Post by Dylan16807 »

btown wrote: post #40
jerf wrote: post #32

Earlier quoted context omitted.

Then you, or someone else, fix the underlying library. This being Postgres, that process was likely completed decades ago. Anticipating the next question, "but what if it is still unsafe?", the answer is that there is no fundamental reason why this can't be safe code. Security exploits like this require a cooperation between the receiving code and the incoming data, and it is in fact perfectly possible for the receiv…

There's some nuance here. Even the most battle-tested system, with distinct slots for executable code and primitive values, might have a way in which an untrusted primitive input can overrun a buffer, or be split in an unsafe way, and cause unexpected behavior. But there's a vast difference in attack surface between that, and "just give us a string, don't worry we'll sanitize it on our end." It's all about defense in…

> But there's a vast difference in attack surface between that, and "just give us a string, don't worry we'll sanitize it on our end."

If you have a type system that distinguishes between sanitized and unsanitized strings then it's not a very big difference in attack surface.

The main difference between the two methods is the risk that you can forget to sanitize. But that's not what happened here, so calling them dumb for having that risk is not a useful way to analyze the problem.

Parameters are not an extra layer of defense. For anything other than forgetting to sanitize, parameters are a sidegrade, not defense in depth.

Post reply on HN