Skip to content
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

stun.Username and stun.MessageIntegrity are not checked #19

Closed
kixelated opened this issue Apr 12, 2019 · 0 comments · Fixed by #22
Closed

stun.Username and stun.MessageIntegrity are not checked #19

kixelated opened this issue Apr 12, 2019 · 0 comments · Fixed by #22
Assignees

Comments

@kixelated
Copy link
Contributor

Pions does not actually check if the remote username/password is correct. A bad entity could use this to hijack a session by sending a STUN packet with maxed out priority. The contents would still be encrypted using DTLS/SRTP, but it would kill the session and open up those protocols to man-in-the-middle attacks.

Sean-Der added a commit that referenced this issue Apr 13, 2019
When we get an inbound message assert these values, also discard any
other packet types besides binding. In the future we should extend to
handle inbound error messages

Resolves #19
Sean-Der added a commit that referenced this issue Apr 13, 2019
When we get an inbound message assert these values, also discard any
other packet types besides binding. In the future we should extend to
handle inbound error messages

Resolves #19
@Sean-Der Sean-Der self-assigned this Apr 13, 2019
Sean-Der added a commit that referenced this issue Apr 13, 2019
When we get an inbound message assert these values, also discard any
other packet types besides binding. In the future we should extend to
handle inbound error messages

Resolves #19
Sean-Der added a commit that referenced this issue Apr 13, 2019
When we get an inbound message assert these values, also discard any
other packet types besides binding. In the future we should extend to
handle inbound error messages

Resolves #19
Sean-Der added a commit that referenced this issue Apr 13, 2019
When we get an inbound message assert these values, also discard any
other packet types besides binding. In the future we should extend to
handle inbound error messages

Resolves #19
Sean-Der added a commit that referenced this issue Apr 14, 2019
When we get an inbound message assert these values, also discard any
other packet types besides binding. In the future we should extend to
handle inbound error messages

Resolves #19
Sean-Der added a commit that referenced this issue Apr 14, 2019
When we get an inbound message assert these values, also discard any
other packet types besides binding. In the future we should extend to
handle inbound error messages

Resolves #19
Sean-Der added a commit that referenced this issue Apr 14, 2019
When we get an inbound message assert these values, also discard any
other packet types besides binding. In the future we should extend to
handle inbound error messages

Resolves #19
Resolves #21
Sean-Der added a commit that referenced this issue Apr 14, 2019
When we get an inbound message assert these values, also discard any
other packet types besides binding. In the future we should extend to
handle inbound error messages

Resolves #19
Resolves #21
Sean-Der added a commit that referenced this issue Apr 14, 2019
When we get an inbound message assert these values, also discard any
other packet types besides binding. In the future we should extend to
handle inbound error messages

Resolves #19
Resolves #21
Sean-Der added a commit that referenced this issue Apr 14, 2019
When we get an inbound message assert these values, also discard any
other packet types besides binding. In the future we should extend to
handle inbound error messages

Resolves #19
Resolves #21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

2 participants