Ungraceful error if can't contact proxy

[digininja]

OS Used - ALL Information (architecture, linux flavor, etc.)

Kali up to date

Error you are encountering

Set http_proxy to a proxy that doesn't exist:

$ export http_proxy=http://localhost:3140

Run EW:

$ ./EyeWitness.py  --single https://localhost

Get the error:

################################################################################
#                                  EyeWitness                                  #
################################################################################
#           Red Siege Information Security - https://www.redsiege.com           #
################################################################################

HTTPConnectionPool(host='localhost', port=3140): Max retries exceeded with url: http://localhost:44105/session (Caused by ProxyError('Cannot connect to proxy.', NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f768ed18fd0>: Failed to establish a new connection: [Errno 111] Connection refused')))

Expected behaviour (vs. what you encountered)

Catch the error and handle it nicely.

Any additional information

Only a fool would eat a Marmite/stroopwafel sandwich!

[Relkci]

Reproduced and confirmed.

Occurs in selenium driver initialize and Try: does not catch the stdout despite dropping into except as expected, but not before allowing the driver's error to stdout.

Likely fix is to redirect the thread's std out temporarily while the driver is being initialized, then resetting it back immediately afterwards.

That said, I'm not certain that's the best direction to go- messing with stdout unnecessarily. Having an incorrect/not-available proxy probably deserves an error that tells the problem. Despite the error not looking pretty, it defines the problem somewhat well.

Maybe not handling the error is ok in this case?

Perhaps a preceding stdout if the env var is set that's causing the error would be enough to help the user identify the root cause?

[Relkci]

produced a POC, will create a proper branch and MR (minus the typos)

since the driver is created in a multithreaded process, the try properly drops to exception, but is in a subprocess with an unhandled sdterr. Adding a try to the driver init allows catching of the error and allows the thread to exit gracefully

selenium_module: -- push driver init into try

eyewitness main

force thread exit if driver failed to init

[digininja]

I've raised a lot of stuff in here that I've completely forgotten about!