Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
New CLI arguments and experimental code coverage #508
base: master
Are you sure you want to change the base?
New CLI arguments and experimental code coverage #508
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
There are no files selected for viewing
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.
While working with boofuzz, I realized that the past design choice to return
b""
on timeout, combined with the fact that the underlying socket API hasrecv
return 0 to indicated a closed connection, leads to an ambiguity: a return value ofb""
can mean a closed connection, or a timeout.My solution was to throw an exception to indicate the socket has shut down, which is more intuitive to me personally. However, this actually flips the semantics of
recv
, which throwssocket.timeout
on timeout and returnsb""
on socket shutdown. Perhaps it would be wiser to follow this approach to map better to peoples' existing knowledge.Either way, we have some choice to make:
Edit: This change seems to be where the test failures are coming from.
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.
On the other hand, I don't know how many scripts out there would actually hit this compatibility problem.
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.
Perhaps one tool to compare with is pwntools, which also has a recv method for which timeout returns an empty bytes, and a closed connection yields an exception: https://docs.pwntools.com/en/stable/tubes.html#pwnlib.tubes.tube.tube.recv
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.
Hmm difficult choice.
I don't like the existing behaviour because we can't differentiate a close from a timeout. So I'd say either stick to the default socket/posix behaviour or raise an exception for everything.
The default posix way would be choice 2 if I understand correctly. Raise socket.timeout and return b"" on close.
However, as we are on application level I could also imagine raising an exception for both cases. Not sure what others think about this but it might be the most user friendly. You simply tell boofuzz to receive after a test case and if anything goes wrong (close/timeout/abort/reset) you get an exception.
On the other hand, I know some of my targets close the connection if the received data was invalid. In that case the target didn't crash but boofuzz would raise an exception. That might be a bit inconvenient.
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?Right now I favour choice 2 as anyone with basic knowledge about sockets will understand what's going on. Also it looks like that approach could easily be adapted to the current
check_data_received_each_request
behaviour.BTW how can we get EWOULDBLOCK if we use a blocking socket and catch socket.timeout before?
boofuzz/boofuzz/connections/tcp_socket_connection.py
Line 131 in 68ad063
And why do we interpret ETIMEDOUT as BoofuzzTargetConnectionReset?
boofuzz/boofuzz/connections/tcp_socket_connection.py
Line 129 in 68ad063
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.
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:
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.