Live data from Hacker News

Hidden Messages in Emojis and Hacking the US Treasury

slamdunksoftware.substack.com

1–10 of 82 posts

Re: Hidden Messages in Emojis and Hacking the US Treasury

#3
post #2

As someone who’s done a fair amount with parsing of Unicode strings lately, I’m not at all surprised by this bug. Unicode is a surprisingly elegant system but also an open invitation for all kinds of abuse.

I havent deep dived unicode enough to know, and probably someone somewhere already made it, but I often wonder if we can do compression more efficiently by abusing unicode somehow, especially regarding plain text.

Re: Hidden Messages in Emojis and Hacking the US Treasury

#4
So many questions:

- why a no side-effects function on a database can be used to get lateral access to the whole database instance

- why do you need to validate strings on the database itself and not on the client anyway, heck why are there no type safe way of doing it

- why would you want to execute shell commands from the database itself

- Even if there's a real use case for executing commands like that why is it enabled by default on a regular connection to the database without you specifying a THIS_IS_REALLY_DANGEROUS_BUT_I_PINKY_PROMISE_I_KNOW_WHAT_IM_DOING flag to the connection handshake.

It's not always PHP but there are some kirks that are shrugged off on PHP that makes me really concerned about the reliability of projects coded with it.

Re: Hidden Messages in Emojis and Hacking the US Treasury

#6
>Beyond Trust did their due diligence by properly calling a sanitization method on the user’s string input using it in a PostgreSQL query.

This is not due diligence. In band messaging of user controlled data has been proven to be bad for security and this is not the first time "escaping" user controlled data for SQL has been done incorrectly.

Re: Hidden Messages in Emojis and Hacking the US Treasury

#7
> Now, all of this might have been fine had Beyond Trust not written a feature which allowed users to directly, programmatically interact with psql (the postgres command line interface).

That's the buried lede.

Yes, there was a vulnerability in psql... but that's so much less a problem than the huge gaping hole of allowing users to directly interact with psql.

No DB can be safe if you are turning untrusted user commands into psql executions. It'd be like giving untrusted users ssh access and then complaining when they find a privilege elevation exploit.

Re: Hidden Messages in Emojis and Hacking the US Treasury

#8
post #4

So many questions: - why a no side-effects function on a database can be used to get lateral access to the whole database instance - why do you need to validate strings on the database itself and not on the client anyway, heck why are there no type safe way of doing it - why would you want to execute shell commands from the database itself - Even if there's a real use case for executing commands like that why is it e…

Your questions are programming language agnostic-- where did your PHP angst come in? And are there specific things in PHP that are problematic and avoidable by using a different Turing complete language?

Re: Hidden Messages in Emojis and Hacking the US Treasury

#9
post #2

As someone who’s done a fair amount with parsing of Unicode strings lately, I’m not at all surprised by this bug. Unicode is a surprisingly elegant system but also an open invitation for all kinds of abuse.

I havent deep dived unicode enough to know, and probably someone somewhere already made it, but I often wonder if we can do compression more efficiently by abusing unicode somehow, especially regarding plain text.

I swear qntm has written something about this.

Re: Hidden Messages in Emojis and Hacking the US Treasury

#10
post #4

So many questions: - why a no side-effects function on a database can be used to get lateral access to the whole database instance - why do you need to validate strings on the database itself and not on the client anyway, heck why are there no type safe way of doing it - why would you want to execute shell commands from the database itself - Even if there's a real use case for executing commands like that why is it e…

They mentioned PAM module so maybe the sql injection just allowed bypassing the authorization of a system that was using the PAM module. Like it’s in the realm of possibility that a PAM module that wanted to validate a user against credentials stored in a pg database might shell out to the psql command to do this. Though, the whole thing is very questionable.
Post reply on HN