You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is an extremely dangerous line of code. If you every hit EBADF on close then you know all bets are off and the only thing you should do is crash. Why so extreme? If some piece of code lost track of the file descriptors and closed 'the wrong one', security vulnerabilities will happen.
For example:
A confused piece of code accidentally double-closes
letfd=openSomething() // A
defer{try?close(fd) // B
}[...]write(fd,"some data",...) // C
try?close(fd) // D
this looks harmless because it looks somewhat sensible that close would be able to detect a failure to close. But that is not true on UNIX because POSIX guarantees to always use the lowest available fd number.
So the above piece of code will absolutely close an unrelated file descriptor if some other thread opens a file descriptor between point A and D which is very likely. Now it might sound kinda harmless to accidentally close an unrelated file descriptor but it's really not. This is how security vulnerabilities are made: If we closed an unrelated file descriptor a 'hole' opens up in the file descriptor table that will often promptly be filled with something else. This means that writes of sensitive data might hit unrelated network connections or files. I have personally seen a process that I worked on that has sent sensitive data means for one HTTP connection into another HTTP connection by accident. It was medical data...
The text was updated successfully, but these errors were encountered:
The only correct way to handle EBADF is to preconditionFailure("hit EBADF -- something closed owned file descriptor \(fd)"). See SwiftNIO code which handles that correctly.
swift-subprocess/Sources/Subprocess/Configuration.swift
Lines 829 to 831 in c0bbfa5
This is an extremely dangerous line of code. If you every hit
EBADF
onclose
then you know all bets are off and the only thing you should do is crash. Why so extreme? If some piece of code lost track of the file descriptors and closed 'the wrong one', security vulnerabilities will happen.For example:
A confused piece of code accidentally double-closes
this looks harmless because it looks somewhat sensible that
close
would be able to detect a failure to close. But that is not true on UNIX because POSIX guarantees to always use the lowest available fd number.So the above piece of code will absolutely close an unrelated file descriptor if some other thread opens a file descriptor between point A and D which is very likely. Now it might sound kinda harmless to accidentally close an unrelated file descriptor but it's really not. This is how security vulnerabilities are made: If we closed an unrelated file descriptor a 'hole' opens up in the file descriptor table that will often promptly be filled with something else. This means that writes of sensitive data might hit unrelated network connections or files. I have personally seen a process that I worked on that has sent sensitive data means for one HTTP connection into another HTTP connection by accident. It was medical data...
The text was updated successfully, but these errors were encountered: