From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bruce Blodgett To: gcc@gcc.gnu.org Cc: "Blodgett, Bruce W." Subject: [Fwd: Simple OS Security Idea] Date: Wed, 18 Jul 2001 08:38:00 -0000 Message-id: <3B55B2C7.6C43EEEF@mitre.org> X-SW-Source: 2001-07/msg01268.html Content-type: multipart/mixed; boundary="----------=_1583532979-674-44" This is a multi-part message in MIME format... ------------=_1583532979-674-44 Content-length: 2426 GCC developers, Although my background is in compilers, I'm not up on the current nuances and ramifications of nonstandard calling conventions, so I don't feel qualified to modify GCC myself. However... My goal is to get the idea below across to more people. Please forward my original message to all appropriate parties. I just ask that you cc: blodgett@mitre.org when you do so. Thank you. --- Bruce Richard Stallman replied: ... > As for why this calling convention is not used, that is partly because > GCC supports the standard calling convention of each machine. To use > a nonstandard calling convention is rather a pain. > > But it is not impossible. If someone wants to do it, I guess that > implementing the nonstandard convention in GCC would be the first > step. > > If you are interested in working on it, please write to gcc@gcc.gnu.org. -------- Original Message -------- Date: Mon, 16 Jul 2001 18:28:24 -0400 From: Bruce Blodgett To: rms@ai.mit.edu Hello. I'm concerned about the current lack of security in today's operating systems and core applications. I have an idea that seems obvious to me, and am looking for help in communicating it to those who can implement it. Given that buffer overflows account for a huge number of exploits: Why don't the OS developers simply compile their code in such a way that all (currently stack-based) buffers and (currently stack-based) return addresses are allocated in unrelated separate storage areas? (Then, knowing one address would be of no use in determining the other, so overflowing a buffer could not overwrite the return address). I find it hard to believe that the current Vulnerable Stack Layout (VSL) is the only efficient layout. If there exists a NonVulnerable Layout (NVL) that is similarly efficient, I find it surprising that compiler writers still implement today's VSL. Even if the best NVL sacrifices a little efficiency for the sake of security, I'm surprised that NVL isn't the default. The more efficient VSL could still be used whenever the compiler can guarantee (or the aggressive user switch promises) that the resulting generated code is not vulnerable to buffer overflow attacks. Bruce Blodgett Mitre Corporation (781) 271-7813 P.S. Any ideas regarding implementation of an efficient NVL? P.P.S. How can I spread this idea to those who can effect this change? S/MIME Cryptographic Signature ------------=_1583532979-674-44 Content-Type: application/octet-stream; charset=binary; name="smime.p7s" Content-Disposition: inline; filename="smime.p7s" Content-Transfer-Encoding: base64 Content-Length: 2355 MIIGwwYJKoZIhvcNAQcCoIIGtDCCBrACAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBOAwggJzMIIB3KADAgECAgIKUDANBgkqhkiG9w0BAQQFADBL MRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1 dGhvcml0eTEVMBMGA1UEAxMMY2EubWl0cmUub3JnMB4XDTAwMTIxODE5MDky NloXDTAyMDYxMTE5MDkyNlowgYsxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlt aXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEYMBYGCgmSJomT8ixkAQETCGJs b2RnZXR0MRowGAYDVQQDExFCbG9kZ2V0dCxCcnVjZSBXLjEhMB8GCSqGSIb3 DQEJARYSYmxvZGdldHRAbWl0cmUub3JnMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQDR3k4+vrvrzNep5n3BSJH5YG4pSizKEpyXBIhqwDp12GCPE8cb /8HjfjEeHBAeR38ichJIi6G4d4Pyc3clVjRF2X0VUFGZitwrX6jfsEvuMbPI OPwrAlOnKW7+/QPhteFe5AkTzeg0uxdPiUFJAw61ztdrGNIGn+sR2UUwsk7J /wIDAQABoyUwIzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXg MA0GCSqGSIb3DQEBBAUAA4GBAMQEdxcJLEdzcBEjyC8crngFldnJDgF55KWs muHtSOWUR7lMYB4IOZbfMGlBeYL0P5vscm7woBjjdUz3PNIjtcgrAoFR6vXC KYhlUivrpqdrC8Kq3QiowpdH5Kk2e7RoNtLGJftXoBTHbnO9i/cdKoVzN0hx nhaTiDRjUA7ak7B6MIICZTCCAc6gAwIBAgIBBTANBgkqhkiG9w0BAQQFADBP MRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1 dGhvcml0eTEZMBcGA1UEAxMQcm9vdGNhLm1pdHJlLm9yZzAeFw05ODA5MDkx NjQ4NTJaFw0wNzA5MDcxNjQ4NTJaMEsxEjAQBgNVBAoTCW1pdHJlLm9yZzEe MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MRUwEwYDVQQDEwxjYS5t aXRyZS5vcmcwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM6K1dCL4VTS hZUcn1sDzOvDo0hTp025906WmOnGhLx/2QEUmb7pZS77+T1/nqmthxtoZXwj BYWPTFCnoD/1xXks28NdGVZRvRDOtEbpDvTwadtbzfXQp/fwFNPcnL8+UgyM 7G2ZnakPNDTAf0ZcY4Z4P+g6177smfPplwYPWdZHAgMBAAGjVTBTMBEGCWCG SAGG+EIBAQQEAwIABzAfBgNVHSMEGDAWgBSaU2bHq4MlY+ThWyYZdbxqjDQ/ XTAdBgNVHQ4EFgQUqTMTu3doqXs3nKOJAaaKMXIkFmkwDQYJKoZIhvcNAQEE BQADgYEAbWXGjCtdKYAD6El1yMDAo9o4xya8UAX01cK2ObyX89ejLkwBSNdv cM094nLJNhblh9wgUP2K6PtlJHvBhykjwv+Pi/dc4o2IEzNzDdKRV8Hs2ncL 55HL5FDiJYzkmzR8Pu2ap10Bb2tVdFERhC0h6RCesI75QQwa23fwyzCV9sEx ggGrMIIBpwIBATBRMEsxEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMV Q2VydGlmaWNhdGUgQXV0aG9yaXR5MRUwEwYDVQQDEwxjYS5taXRyZS5vcmcC AgpQMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMDEwNzE4MTYwMTExWjAjBgkqhkiG9w0BCQQxFgQU F76zF8Re2e2qSPjDjXgTV73cC3owUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAw DQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYA7QCZN4qvBW21HEbKA 0H/evmDpvdl7/iuetg2qixibdAXcK9Df6tgA4boM0gHaYgsOQ43AVGE3BZyK 6wmarUg+sL6OI+D/jYpmgoYJBqGXcgiHF0DlT5c33n2QD21geybwbPRiusCg o/XYyNsVnHHswNB4VUZHAW1PSwozHfbDsg== ------------=_1583532979-674-44--