{"status":"ok","message-type":"work","message-version":"1.0.0","message":{"indexed":{"date-parts":[[2025,6,19]],"date-time":"2025-06-19T04:56:10Z","timestamp":1750308970031,"version":"3.41.0"},"reference-count":0,"publisher":"Association for Computing Machinery (ACM)","issue":"3","license":[{"start":{"date-parts":[[2004,5,1]],"date-time":"2004-05-01T00:00:00Z","timestamp":1083369600000},"content-version":"vor","delay-in-days":0,"URL":"https:\/\/www.acm.org\/publications\/policies\/copyright_policy#Background"}],"content-domain":{"domain":["dl.acm.org"],"crossmark-restriction":true},"short-container-title":["Queue"],"published-print":{"date-parts":[[2004,5]]},"abstract":"<jats:p>In January 2003, the Slammer worm was reported to be the fastest spreading ever. Slammer gets access by exploiting a buffer overrun. If you peruse CERT advisories or security upgrade releases, you will see that the majority of computer security holes are buffer overruns. These would be minor irritations but for the world\u2019s addiction to the weakly typed programming languages C and its derivative C++. Buffer overruns are a kind of array bounds error. There are many variations on how one might actually happen, but here is a typical scenario. Function F calls function G, and G returns a string. F allocates a buffer to hold the result and passes a pointer to its zeroth character. G gets the string from somewhere, perhaps a network connection, and copies it into the buffer supplied by F.<\/jats:p>","DOI":"10.1145\/1005062.1005075","type":"journal-article","created":{"date-parts":[[2005,1,26]],"date-time":"2005-01-26T16:33:14Z","timestamp":1106757194000},"page":"12-14","update-policy":"https:\/\/doi.org\/10.1145\/crossmark-policy","source":"Crossref","is-referenced-by-count":0,"title":["Opinion: Buffer Overrun Madness"],"prefix":"10.1145","volume":"2","author":[{"given":"Rodney","family":"Bates","sequence":"first","affiliation":[{"name":"Wichita State University"}],"role":[{"role":"author","vocabulary":"crossref"}]}],"member":"320","published-online":{"date-parts":[[2004,5]]},"container-title":["Queue"],"original-title":[],"language":"en","link":[{"URL":"https:\/\/dl.acm.org\/doi\/10.1145\/1005062.1005075","content-type":"unspecified","content-version":"vor","intended-application":"text-mining"},{"URL":"https:\/\/dl.acm.org\/doi\/pdf\/10.1145\/1005062.1005075","content-type":"unspecified","content-version":"vor","intended-application":"similarity-checking"}],"deposited":{"date-parts":[[2025,6,18]],"date-time":"2025-06-18T21:38:33Z","timestamp":1750282713000},"score":1,"resource":{"primary":{"URL":"https:\/\/dl.acm.org\/doi\/10.1145\/1005062.1005075"}},"subtitle":["Why do good programmers follow bad practices?"],"short-title":[],"issued":{"date-parts":[[2004,5]]},"references-count":0,"journal-issue":{"issue":"3","published-print":{"date-parts":[[2004,5]]}},"alternative-id":["10.1145\/1005062.1005075"],"URL":"https:\/\/doi.org\/10.1145\/1005062.1005075","relation":{},"ISSN":["1542-7730","1542-7749"],"issn-type":[{"type":"print","value":"1542-7730"},{"type":"electronic","value":"1542-7749"}],"subject":[],"published":{"date-parts":[[2004,5]]},"assertion":[{"value":"2004-05-01","order":2,"name":"published","label":"Published","group":{"name":"publication_history","label":"Publication History"}}]}}