On 2017-04-26 11:47, Lifepillar wrote:
> On 12/04/2017 10:57, vinny wrote:
>> On 2017-04-12 09:09, Lifepillar wrote:
>>> So, I am here to ask if you have
>>> interesting/(in)famous stories to share on database security/privacy
>>> "gone wrong" or "done right"(tm), possibly with technical details
>>
>> One case that I remember from an ancient version of the book "hacking
>> exposed"
>> was about a MySQL server that was running under the root user. A badly
>> written
>> application allowed some SQL injection that let a hacker issue a
>> SELECT
>> INTO OUTFILE
>> query that "selected" a bash script into the .login file of the root
>> user,
>> and the next time the root user logged in, the script would create a
>> new
>> superuser account
>> for the hacker.
>
> After tweaking MySQL to be really insecure by unsetting
> secure_file_prev, using grant file, etc..., I am indeed able to write
MySQL used to be "really insecure", I'm glad to see they have taken
measures
to prevent this attack. (now let's just hope that you cannot use SQL
to change tose security settings :-)
>
> Correct me if I am wrong, in PostgreSQL something similar can be
> achieved using lo_export(), although you must connect as a superuser to
> do that (while in MySQL you may grant file system access to any user).
Technically, yes, but you cannot supply a path as easily as in MySQL.
The moral of the story is not so much that MySQL is unsafe, but that
attacks
can come from the most unexpected places. Even from things you did not
even know
to be possible. Again: if something sis not required to be possible,
then measures should be taken to make it impossible.