-
Notifications
You must be signed in to change notification settings - Fork 382
New CLI arguments and experimental code coverage #508
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Changes from 16 commits
0d110de
845b039
54772b1
164f7d8
6011f9e
f0465d4
982a12a
33a7800
579cb75
4503e31
75b6ab2
81f660c
f1825f3
9426465
de3ed7d
68ad063
44baaa3
33fe390
0f77469
366326b
dceeac7
5239677
b04709f
be17dd3
44c2f40
5a3d362
0da9d85
68de3c5
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -21,18 +21,32 @@ class TCPSocketConnection(base_socket_connection.BaseSocketConnection): | |||||
| send_timeout (float): Seconds to wait for send before timing out. Default 5.0. | ||||||
| recv_timeout (float): Seconds to wait for recv before timing out. Default 5.0. | ||||||
| server (bool): Set to True to enable server side fuzzing. | ||||||
| graceful_shutdown (bool): close() method attempts a graceful shutdown. Default: True. | ||||||
|
|
||||||
| """ | ||||||
|
|
||||||
| def __init__(self, host, port, send_timeout=5.0, recv_timeout=5.0, server=False): | ||||||
| def __init__(self, host, port, send_timeout=5.0, recv_timeout=5.0, server=False, graceful_shutdown=True): | ||||||
| super(TCPSocketConnection, self).__init__(send_timeout, recv_timeout) | ||||||
|
|
||||||
| self.host = host | ||||||
| self.port = port | ||||||
| self.server = server | ||||||
| self._serverSock = None | ||||||
| self.graceful_shutdown = graceful_shutdown | ||||||
|
|
||||||
| def close(self): | ||||||
| if self.graceful_shutdown: | ||||||
| try: | ||||||
| self._sock.shutdown(socket.SHUT_RDWR) | ||||||
| while len(self._sock.recv(1024)) > 0: | ||||||
| pass | ||||||
| except ConnectionError: | ||||||
SR4ven marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
| pass | ||||||
| except OSError as e: | ||||||
| if e.errno == errno.ENOTCONN: | ||||||
| pass | ||||||
| else: | ||||||
| raise | ||||||
| super(TCPSocketConnection, self).close() | ||||||
|
|
||||||
| if self.server: | ||||||
|
|
@@ -84,18 +98,25 @@ def _connect_socket(self): | |||||
|
|
||||||
| def recv(self, max_bytes): | ||||||
| """ | ||||||
| Receive up to max_bytes data from the target. | ||||||
| Receive up to max_bytes data from the target. Timeout results in 0 bytes returned. | ||||||
|
|
||||||
| Args: | ||||||
| max_bytes (int): Maximum number of bytes to receive. | ||||||
|
|
||||||
| Returns: | ||||||
| Received data. | ||||||
| Received data (empty bytes array if timed out). | ||||||
|
|
||||||
| Raises: | ||||||
| BoofuzzTargetConnectionShutdown: Target shutdown connection (e.g. socket recv returns 0 bytes) | ||||||
| BoofuzzTargetConnectionAborted: ECONNABORTED | ||||||
| BoofuzzTargetConnectionReset: ECONNRESET, ENETRESET, ETIMEDOUT | ||||||
| """ | ||||||
| data = b"" | ||||||
|
|
||||||
| try: | ||||||
| data = self._sock.recv(max_bytes) | ||||||
| if len(data) == 0: | ||||||
| raise exception.BoofuzzTargetConnectionShutdown() | ||||||
|
||||||
| elif e.errno == errno.EWOULDBLOCK: # timeout condition if using SO_RCVTIMEO or SO_SNDTIMEO |
And why do we interpret ETIMEDOUT as BoofuzzTargetConnectionReset?
| elif (e.errno == errno.ECONNRESET) or (e.errno == errno.ENETRESET) or (e.errno == errno.ETIMEDOUT): |
Edit: I wouldn't worry about breaking backwards compatibility. As you already said I doubt that many scripts use the boofuzz socket interface directly and rely on this specific behaviour.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also just found the session option check_data_received_each_request. It seems this option is the reason for both close and timeout returning b"". If we switch to exceptions, we'd have to catch them here and depending on the setup maybe re-raise?
Yes, that Session option is a layer on top of the socket behavior. The only place in my scripts this would matter is in callbacks, where I sometimes have code set up to receive the next (typically valid) message. Whatever choice we make here, we can modify Session to still act the same way with check_data_received_each_request.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Trying to get all these options clear in my head:
----------+--------------+-----------------------+--------------+------------+------------
| | OS socket | OS socket nonblocking | boo previous | PR initial | PR propsed |
+----------+--------------+-----------------------+--------------+------------+------------+
| timeout | wait forever | exception | return b"" | return b"" | exception |
| shutdown | return b"" | return b"" | return b"" | exception | return b"" |
----------+--------------+-----------------------+--------------+------------+------------
Part of me wants to yield an exception in both cases. I'm leaning toward matching OS socket behavior, but that behavior is a bit counterintuitive.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The table seems to be correct.
Agreed, I feel exactly the same way. I think if you have worked with sockets before, the OS socket behaviour is more intuitive.
It's the other way around if you haven't I guess.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Which timeout/shutdown behaviour are we going to use now? The one initially proposed in this PR or the OS like?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@SR4ven The OS-like behavior. Just realized I didn't add the timeout exception though...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright. We don't need BoofuzzTargetConnectionShutdown anymore do we.
Also, do we need to adapt other connection classes to the new behaviour? UDP maybe?
We could do that in another PR if needed.
Uh oh!
There was an error while loading. Please reload this page.