Re: [Sqlgrey-users] Periodic crashes of sqlgrey

[Lionel B. <lio...@bo...>]

HaJo Schatz wrote the following on 17.11.2004 12:36 :

>[...]
>c:documentsandsettingsadministratordesktopgevaliagevaliafroms.txt-at-mail.epelle.co.kr -> [my e-mail address]
>Nov 16 00:29:38 sun sqlgrey[9064]: Warning: couldn't do query: INSERT
>INTO connect (sender_name, sender_domain, ip_addr, rcpt, first_seen)
>VALUES('c:documentsandsettingsadministratordesktopgevaliagevaliafroms.txt', 'mail.epelle.co.kr', '219.254.35.115', '[my e-mail address]', NOW()): , sleeping and reconnecting to DB
>Nov 16 00:29:48 sun sqlgrey[9064]: warning: Database handle destroyed
>without explicit disconnect at /usr/bin/sqlgrey line 178.
>Nov 16 00:29:48 sun sqlgrey[9064]: fatal: Error: db reconnection
>failed:  at /usr/bin/sqlgrey line 77.
>Nov 16 00:29:48 sun postfix/smtpd[5045]: warning: premature end-of-input
>on 127.0.0.1:2501 while reading input attribute name
>[...]
>  
>


If the INSERT can't be done due to some malformed value, this is 
expected. What isn't expected in 1.2.0 or 1.3.x is a malformed valued 
hitting the database.
What surprises me is that your sample shows a 65 characters sender_name 
which :
- is illegal per RFC (but this is a spammer OK);
- is taken into account by sqlgrey-1.2.0 and 1.3.x : there's code 
explicitly trucating sender_name to 64 chars before putting it in database.

I must confess I didn't test this case after coding the protection, but 
I just did and it worked :

c:doc...@ma...
is put in the connect table as :
'c:documentsandsettingsadministratordesktopgevaliagevaliafroms.tx' | 'mail.eppele.co.kr'
(notice the missing 't')

My best guess is that you have an old (1.1.3 wasn't protected against this) sqlgrey release in your $PATH.


>I'm getting these mails about twice a day, so my mail server is
>meanwhile more down than up...
>
>I believe sqlgrey would need some (more -- I understand some has been
>introduced since 1.2.0) sanity checks about values it wants to insert
>into the data base. I smell targeted exploits being possible here...
>  
>

In this particular case, only a DoS (killing sqlgrey at will) would have 
been possible, properly quoting values (which is done in 1.2.0) solves 
the '; DELETE ...' exploits.

Best regards,

Lionel.