PostgreSQL scanner throws stack trace on invalid PG service

[hdm]

The aux/scanner/postgres/postgres_version module should handle non-PG (dead) services better:

[*] [2015.09.11-10:01:23] a.b.c.d:5433 Postgres - Trying username:'postgres' with password:'INVALID_yuitFC' against a.b.c.d:5433 on database 'template1'
[-] [2015.09.11-10:01:23] Auxiliary failed: NoMethodError undefined method `unpack' for nil:NilClass
[-] [2015.09.11-10:01:23] Call stack:
[-] [2015.09.11-10:01:23]   /opt/metasploit.new/apps/pro/msf3/lib/postgres/postgres-pr/message.rb:47:in `read'
[-] [2015.09.11-10:01:23]   /opt/metasploit.new/apps/pro/msf3/lib/postgres/postgres-pr/connection.rb:71:in `block in initialize'
[-] [2015.09.11-10:01:23]   /opt/metasploit.new/apps/pro/msf3/lib/postgres/postgres-pr/connection.rb:70:in `loop'
[-] [2015.09.11-10:01:23]   /opt/metasploit.new/apps/pro/msf3/lib/postgres/postgres-pr/connection.rb:70:in `initialize'
[-] [2015.09.11-10:01:23]   /opt/metasploit.new/apps/pro/msf3/lib/msf/core/exploit/postgres.rb:226:in `new'
[-] [2015.09.11-10:01:23]   /opt/metasploit.new/apps/pro/msf3/lib/msf/core/exploit/postgres.rb:226:in `postgres_fingerprint'
[-] [2015.09.11-10:01:23]   /opt/metasploit.new/apps/pro/msf3/modules/auxiliary/scanner/postgres/postgres_version.rb:58:in `do_fingerprint'
[-] [2015.09.11-10:01:23]   /opt/metasploit.new/apps/pro/msf3/modules/auxiliary/scanner/postgres/postgres_version.rb:40:in `run_host'
[-] [2015.09.11-10:01:23]   /opt/metasploit.new/apps/pro/msf3/lib/msf/core/auxiliary/scanner.rb:116:in `block (2 levels) in run'
[-] [2015.09.11-10:01:23]   /opt/metasploit.new/apps/pro/msf3/lib/msf/core/thread_manager.rb:100:in `call'
[-] [2015.09.11-10:01:23]   /opt/metasploit.new/apps/pro/msf3/lib/msf/core/thread_manager.rb:100:in `block in spawn'

[nstarke]

I tested this and cannot reproduce the exact error, however if I do something like nc -l -p 3000 and then set RPORT to 3000 and run this module, then kill the nc process during the connection attempt, I get the following error:

msf auxiliary(postgres_version) > set RPORT 3000
RPORT => 3000
msf auxiliary(postgres_version) > run

[-] Auxiliary failed: NoMethodError undefined method `>=' for nil:NilClass
[-] Call stack:
[-]   /media/psf/Home/Documents/development/open-source/metasploit-framework/lib/postgres/postgres-pr/message.rb:49:in `read'
[-]   /media/psf/Home/Documents/development/open-source/metasploit-framework/lib/postgres/postgres-pr/connection.rb:71:in `block in initialize'
[-]   /media/psf/Home/Documents/development/open-source/metasploit-framework/lib/postgres/postgres-pr/connection.rb:70:in `loop'
[-]   /media/psf/Home/Documents/development/open-source/metasploit-framework/lib/postgres/postgres-pr/connection.rb:70:in `initialize'
[-]   /media/psf/Home/Documents/development/open-source/metasploit-framework/lib/msf/core/exploit/postgres.rb:226:in `new'
[-]   /media/psf/Home/Documents/development/open-source/metasploit-framework/lib/msf/core/exploit/postgres.rb:226:in `postgres_fingerprint'
[-]   /media/psf/Home/Documents/development/open-source/metasploit-framework/modules/auxiliary/scanner/postgres/postgres_version.rb:84:in `do_fingerprint'
[-]   /media/psf/Home/Documents/development/open-source/metasploit-framework/modules/auxiliary/scanner/postgres/postgres_version.rb:40:in `run_host'
[-]   /media/psf/Home/Documents/development/open-source/metasploit-framework/lib/msf/core/auxiliary/scanner.rb:116:in `block (2 levels) in run'
[-]   /media/psf/Home/Documents/development/open-source/metasploit-framework/lib/msf/core/thread_manager.rb:100:in `call'
[-]   /media/psf/Home/Documents/development/open-source/metasploit-framework/lib/msf/core/thread_manager.rb:100:in `block in spawn'
[*] Auxiliary module execution completed

This error is similar, but not the same as the original bug.

Running against a dead port, such as 5433, results in the following:

msf auxiliary(postgres_version) > set RPORT 5433
RPORT => 5433
msf auxiliary(postgres_version) > run

[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf auxiliary(postgres_version) > 

Is this ticket still valid?

[wchen-r7]

It seems this bug was fixed in #6079

I also can no longer reproduce the problem, so I think it's safe to close this ticket now.