One Article Review
| Source |  Errata Security |
|---|---|
| Identifiant | 855595 |
| Date de publication | 2018-10-21 18:10:54 (vue: 2018-10-22 01:05:04) |
| Titre | TCP/IP, Sockets, and SIGPIPE |
| Texte | There is a spectre haunting the Internet -- the spectre of SIGPIPE errors. It's a bug in the original design of Unix networking from 1981 that is perpetuated by college textbooks, which teach students to ignore it. As a consequence, sometimes software unexpectedly crashes. This is particularly acute on industrial and medical networks, where security professionals can't run port/security scans for fear of crashing critical devices.An example of why this bug persists is the well-known college textbook "Unix Network Programming" by Richard Stevens. In section 5.13, he correctly describes the problem.When a process writes to a socket that has received an RST, the SIGPIPE signal is sent to the process. The default action of this signal is to terminate the process, so the process must catch the signal to avoid being involuntarily terminated.This description is accurate. The "Sockets" network APIs was based on the "pipes" interprocess communication when TCP/IP was first added to the Unix operating system back in 1981. This made it straightforward and comprehensible to the programmers at the time. This SIGPIPE behavior made sense when piping the output of one program to another program on the command-line, as is typical under Unix: if the receiver of the data crashes, then you want the sender of the data to also stop running. But it's not the behavior you want for networking. Server processes need to continue running even if a client crashes.But Steven's description is insufficient. It portrays this problem as optional, that only exists if the other side of the connection is misbehaving. He never mentions the problem outside this section, and none of his example code handles the problem. Thus, if you base your code on Steven's, it'll inherit this problem and sometimes crash.The simplest solution is to configure the program to ignore the signal, such as putting the following line of code in your main() function: signal(SIGPIPE, SIG_IGN);If you search popular projects, you'll find that this there solution most of the time, such as openssl.But there is a problem with this approach, as OpenSSL demonstrates: it's both a command-line program and a library. The command-line program handles this error, but the library doesn't. This means that using the SSL_write() function to send encrypted data may encounter this error. Nowhere in the OpenSSL documentation does it mention that the user of the library needs to handle this.Ideally, library writers would like to deal with the problem internally. There are platform-specific ways to deal with this. On Linux, an additional parameter MSG_NOSIGNAL can be added to the send() function. On BSD (including macOS), setsockopt(SO_NOSIGPIPE) can be configured for the socket when it's created (after socket() or after accept()). On Windows and some other operating systems, the SIGPIPE isn't even generated, so nothing needs to be done for those platforms.But it's difficult. Browsing through cross platform projects like curl, which tries this library technique, I see the following bit:#ifdef __SYMBIAN32__/* This isn't actually supported under Symbian OS */#undef SO_NOSIGPIPE |
| Envoyé | Oui |
| Condensat | as at by can for function has or signal */#undef 1981 ;if able accurate action actually acute added additional adequately after accept after socket age all allowed also amount and send annoying another any api apis approach appropriate appropriate #ifdefs are as openssl avoid back bad base based because before behavior being belief bit:#ifdef both breaks browsing bsd buffer bug bugs but call calls send can catch cause causing check client closes code code must deal college command communication completely comprehensible concept conclusioni condition conditions configure configured connection consequence constant continue continuous control controlled correctly corrupted crash crashes crashing create created critical cross data day deal default defined defines definition demonstrates: described describes description design devices difficult discover documentation does doesn doing don done down echo else encounter encrypted enough error errors escapes especially etc even eventually everything exact example except exercises exists factories fails fast fear find first fix fixed following from function generate generated generating get gets hacker hackers handle handles happen happens has haunting have havoc his hit hits hospitals how however ideally ign ignore ignored important including incomplete indeed industrial information inherit input insufficient integration interest interested internally internet interprocess intractable involuntarily is hard is signal isn isolated issue issues just keep know known large later leads let level library like like curl limit line linux long macos made major manufacturer may means medical mention mentions met methods million misbehaving modern more most msg much must necessary need needs network networking networks never non none nosignal nosignal can nosigpipe nosigpipe#endiflater not nothing now nowhere once one only openssl operating optional order original other otherwise outdated output outside packet parameter msg particular particularly peer peers people perpetuate perpetuated persistent persists perspective pipes piping plants platform platforms point popular port/security port/vuln portrays power presents principle problem problems process processes professionals program programmers programming projects properly putting rather received receiver receives recommendation remote repeatedly reset response responsibility returned richard right rst rsts run running same sample scan scanners scans search section security see send sender sending sends sense sent server set setsockopt setsocktopt short side sig signal sigpipe sigprocmask simple simplest socket sockets software solution solving some something sometimes source specific spectre steven stevens stop straightforward students such suites summarize: support supported sure surrounded survive symbian symbian32 system systems taking talk abstract taught tcp/ip teach teaches technique techniques: signal tend terminate terminated test testing textbook textbooks than that the send the ssl them then theoretical theory there these they thing things this:hackers those threads three through thus tightly time times timing ton top traffic tries truly trusting trusts trying typical undefined under understand understanding unexpected unexpectedly unit/regression university unix unix: until use use pthread user using vulnerabilities vulnerable want way ways web webserver well what when where whether which who why will windows won words work worse would write writers writes written wrong yet you your your main |
| Tags | Guideline |
| Stories | |
| Notes | |
| Move | 
|
L'article ne semble pas avoir été repris aprés sa publication.
L'article ne semble pas avoir été repris sur un précédent.