IT-sikkerheds myndighederne i skarpt angreb på C og C++

https://www.cisa.gov/sites/default/files/2023-12/T...

Den korte version:
* ca. 70% af sikkerhedsfejl relaterer sig til memory problemer
* de tror ikke på at udviklere helt kan undgå fejl
* derfor anbefaler de at man laver en roadmap for skift til et memory safe language

TheRegister gør det lidt til pro-Rust i https://www.theregister.com/2023/12/07/memory_corr... men faktisk står der ikke meget om Rust i originalen.

Tja. Rå, ubeskyttet C kodning bliver snart noget mytisk som graybeards kan fortælle om fra computerens barndom.

Det minder mig om "The Story of Mel, a Real Programmer" https://sac.edu/AcademicProgs/Business/ComputerSci... men denne gang er det C koderne der har rollen som de beskrevede "Real Programmers" ingen forstår mere ;)

Fra Story of Mel:

Real Programmers write in FORTRAN.



Maybe they do now,

in this decadent era of

Lite beer, hand calculators, and ``user-friendly'' software

but back in the Good Old Days,

when the term ``software'' sounded funny

and Real Computers were made out of drums and vacuum tubes,

Real Programmers wrote in machine code.

Not FORTRAN. Not RATFOR. Not, even, assembly language.

Machine Code.

Raw, unadorned, inscrutable hexadecimal numbers.

Directly.

#3

Det vil tage lang tid.

Jeg tror på at C og C++ vil være niche i "business applications" om 20-30 år. Der er så mange alternativer der allerede har godt fodfæste: C#, Java, Kotlin, Scala, Groovy, PHP, Python, JavaScript/TypeScript etc.etc..

Men i OS & anden low level kode vil det snarere tage 30-50 år inden C og C++ er niche. Få og meget nye alternativer. Rust og Go får meget positiv omtale men kodemængden er stadig ingenting sammenlignet med C/C++. Zig og Hare er så nye at de fleste kun kender navnene.

#3

Det der er fra meget lang tid siden.

Jeg vil gætte på at idag vil:
* 90% ikke have hørt om hverken Fortran eller RatFor
* 9.9% have hørt om Fortran men ikke om RatFor
* 0.1% have hørt om både Fortran og RatFor

:-)

Men jeg er i de 0.1% hvilket formentligt ikke overrasker nogen.

RatFor var faktisk en ret god ide.

RatFor var et mix af Fortran 66 med C lignende kontrol strukturer. Og det gjorde kode meget meget mere læsbar.

Fortran 66 kode (70'erne):

.      program fortran66
.      integer i
.      real x, dx
.      x = 0.0
.      i = 1
.100   if(mod(i,2).eq.0) goto 200
.      dx = 1.0 / (2 * i - 1)
.      goto 300
.200   dx = -1.0 / (2 * i - 1)
.300   x = x + dx
.      i = i + 1
.      if(abs(dx).gt.0.000001) goto 100
.      x = 4 * x
.      write(*,*) x
.      end

RatFor kode (70'erne):

.program ratfor
.integer i
.real x, dx
.x = 0.0
.dx = 1.0
.i = 1
.while(abs(dx) > 0.000001) {
.  if(mod(i,2) == 1) {
.    dx = 1.0 / (2 * i - 1)
.  } else {
.    dx = -1.0 / (2 * i - 1)
.  }
.  x = x + dx
.  i = i + 1
.}
.x = 4 * x
.write(*,*) x
.end

Fortran 77 med VAX extensions kode (80'erne) - og valid Fortran 90 kode (90'erne):

.      program fortranvax
.      integer i
.      real x, dx
.      x = 0.0
.      dx = 1.0
.      i = 1
.      do while(abs(dx).gt.0.000001)
.        if(mod(i,2).eq.1) then
.          dx = 1.0 / (2 * i - 1)
.        else
.          dx = -1.0 / (2 * i - 1)
.        endif
.        x = x + dx
.        i = i + 1
.      enddo
.      x = 4 * x
.      write(*,*) x
.      end

#3

Med hensyn til hex, så er det kun få måneder siden jeg kom op med den her kode:

#include <stdio.h>

__asm__(
"f:\n"
"_f:\n"
".byte 0x1E\n" // 32 bit mode : push %ds
// 64 bit mode : (undefined)
".byte 0x1F\n" // 32 bit mode : pop %ds
// 64 bit mode : (undefined)
".byte 0xC3\n" // 32 bit mode : ret
// 64 bit mode : ret
);

void f();

int main()
{
printf("Start\n");
f();
printf("Finish\n");
return 0;
}

Den virker som:

arne@arnepc6:~/mode$ bash -v runf2.sh
rm f2
gcc -m32 f2.c -o f2
./f2
Start
Finish
rm f2
gcc -m64 f2.c -o f2
./f2
Start
runf2.sh: line 6: 5175 Illegal instruction (core dumped) ./f2

Ratfor, jeg troede faktisk det var et ordspil på Fortran. Jeg er tydeligvis ikke i de 0.1% ;)

Ja, det kommer til at tage ganske lang tid. Men jeg synes der er en klar parallel. Mel programmerede hardcore maskinkode og udnyttede aspekter som præcis den tid det tager en tromle at rotere en omgang og tricks som at lade carry fra en ADD operation ændre en opkode i næste adresse. - det er low-level fy-fy på et helt andet plan end vi er vandt til i dag.

Nu er C så på vej til at blive det nye low-level fy-fy, fordi der er mere sikre og brugbare alternativer.

Og jeg er slet ikke imod. Det er en god udvikling der fører til bedre kode med færre bugs.

#6 Så 1E 1F C3 er push %ds, pop %ds, ret, i 32-bit x86, men ugyldigt i x64. Meget sødt.

Én byte instruktioner blandt alle de andre længder. Og jeg tænker at ISA ikke kræver alignment overhovedet. Damn... Vores FPGA-mand får et lille flip hver gang vi laver noget der ikke er garanteret 64-bit aligned, for det er den mest bekvemme ordstørrelse i hans verden (og den del af chippen). x86 er sådan et beskidt instruktionssæt.

#6 Jeg får helt det samme på min maskine. Men jeg var nød til at:

sudo apt install gcc-multilib

før jeg kunne compile med -m32

larsp (7) skrev:

Ratfor, jeg troede faktisk det var et ordspil på Fortran.

Ifølge Wikipedia står det for "Rational Fortran".

Og det er iøvrigt Brian Kernighan der opfandt det.

Jeg glemte at nævne at RatFor ikke ovversætter til objekt kode men til Fortran 66 kode. I moderne terminologi er det en transpiler og ikke en compiler.

https://www.bleepingcomputer.com/news/security/whi...

#11 Politikerne vil have mig til at stoppe med at skrive C. Blah. Jeg får faktisk en stærk trang til at finde C frem, selv for nye opgaver nu.

#12

Der er et problem med visse sprog (primært C og C++) og deres memory håndtering. Det er selvfølgelig muligt at skrive korrekt kode. Men erfaring viser at i praksis forefindes der memory leaks og buffer overruns. Udviklerne kender godt problematikken, men sætter man 1000 udviklere til at skrive 5 millioner linier kode, så ender man med et antal memory problemer. Hvis man kombinerer den klassiske 1 fejl per 1000 linier med MS 70% statistikken, så ca. 3500 memory relaterede fejl.

Der er forskellige måder at håndtere det problem på.

A) Sige "sådan er det bare" og gøre ingenting. Det er vel reelt det man har brugt de sidste 40 år.

B) Engineering: developer training, code reviews, coding conventions, static code analysis tools, fuzzing test software etc..

C) Anbefale/kræve brug af sprog som er mere skrappe til at forhindre den slags problemer. USA federal er igang med sådanne anbefalinger. USA har også tidligere forsøgt sig med lignende krav. 1991-1997 var det et krav at software til forsvaret og forsvarsministeriet skulle skrives i Ada (verdens mest type sikre sprog).

D) Lade software producenter frit vælge sprog, men holde dem økonomisk ansvarlige i tilfælde af fejl. Det er den retning EU har - Cyber Resilience Act er et skridt i den retning.

Option A holder ikke længere. For meget er afhængigt af fungerende IT. En ting er eskalerende IT kriminalitet, men hvis kinesiske hackere lukker vesten i 3 uger, så kan følgerne være helt uoverskuelige.

Option B har været forsøgt gennem mange år, men resultaterne har ikke været imponerende generelt set.

Option C er det nyheden drejer sig om.

Option D er på vej i EU. På mange måder er det jo en elegant markedsøkonomisk løsning. Software firmaer vælger selv hvad de vil bruge men er ansvarlig for deres valg og står til ansvar for fejl. De bliver nødt til at tegne en forsikring og forsikringsselskabet stiller forskellige krav alt efter hvordan firmaet griber tingene an. Sjusker man bliver forsikringen dyr har man styr på tingene bliver forsikringen billig. Markedet virker. Det er en løsning som ligner andre brancher. Men det vil ikke fungere i praksis for software. En stor del af software er open source. Ingen firma til at blive holdt ansvarlig.

#13 Jeg ved det da godt. Det er bare mig der er rasmus modsat over for "design per committee" eller endnu værre, "design per politician"

Ethvert software udviklingshus med respekt for dem selv vil ikke vælge C til et nyt projekt, netop pga. alle de problemer du nævner. Det er decideret økonomisk dumt. Der findes nyere og mere sikre sprog vil føre til færre fejl og problemer, mindre ansvar for ulykker osv.

Der er IMO slet ikke behov for løftede pegefingre fra politikere og andre folk i elfensbenstårne. De vil bare lave dumme regler der spænder ben for at vælge de bedste tools til opgaverne. Det kan sagtens tænkes at C vil give mening i nogle embeddede devices der ikke er kritiske, mange år frem.

Jeg vil egentlig mene at kunden skal mere på banen. Kunden bør vide at der findes memory-usikre sprog og at nyere sprog der sikrer mod denne type fejl er blevet ganske modne og brugbare, så kunden bør spørge leverandøren i forhandlingsfasen, hvilken type sprog der skal bruges og fravælge leverandører der insisterer på C eller old-school, ikke-lintet, usikker C++.

Hvis det bliver forbudt at bruge C, så er Linux smidt på porten. Det vil være et ret vidtgående krav. (og Windows, jeg ser at der er masser af C i Windows kernel)

Men til virkeligt kritiske systemer giver det mening.

Ang. Option D. Jeg troede egentlig at der allerede var ansvar under normal produktansvars-lovgivning. Hvis jeg sælger en vandkoger der giver folk stød har jeg et temmeligt stort problem. Er det ikke sådan med software?

larsp (15) skrev:

Ang. Option D. Jeg troede egentlig at der allerede var ansvar under normal produktansvars-lovgivning. Hvis jeg sælger en vandkoger der giver folk stød har jeg et temmeligt stort problem. Er det ikke sådan med software?

Det er sådan med det meste. Hvis en entrepenør bygger en bro og den styrter sammen vild er også blive forlangt erstatning.

Jeg tror ikke at software er eksplicit undtaget i lovgivningen.

Men på trods af at vi hører om masser af sikkerhedsfejl og funktionelle fejl i software, så kan jeg ikke umiddelbart komme i tanke om nogen som har fået erstatning p.g.a. software fejl.

Og diverse licens/EULA tekster er som oftest ret afvisende overfor krav.

https://www.microsoft.com/en-us/Useterms/Retail/Wi...

9. Warranty, Disclaimer, Remedy, Damages and Procedures.

a. Limited Warranty. Depending on how you obtained the Windows software, Microsoft, or the device manufacturer or installer, warrants that properly licensed software will perform substantially as described in any Microsoft materials that accompany the software. This limited warranty does not cover problems that you cause, that arise when you fail to follow instructions, or that are caused by events beyond the reasonable control of Microsoft, or the device manufacturer or installer. The limited warranty starts when the first user acquires the software, and lasts for one year if acquired from Microsoft, or for 90 days if acquired from a device manufacturer or installer. If you obtain updates or supplements directly from Microsoft during the 90-day term of the device manufacturer’s or installer’s limited warranty, Microsoft provides the limited warranty for those updates or supplements. Any supplements, updates, or replacement software that you may receive from Microsoft during that year are also covered, but only for the remainder of that one-year period if acquired from Microsoft, or for 90 days if acquired from a device manufacturer or installer, or for 30 days, whichever is longer. Transferring the software will not extend the limited warranty.

b. Disclaimer. Neither Microsoft, nor the device manufacturer or installer, gives any other express warranties, guarantees, or conditions. Microsoft and the devicemanufacturer and installerexclude all implied warranties and conditions, including those of merchantability, fitness for a particular purpose, and non-infringement. If your local law does not allow the exclusion of implied warranties, then any implied warranties, guarantees, or conditions last only during the term of the limited warranty and are limited as much as your local law allows. If your local law requires a longer limited warranty term, despite this agreement, then that longer term will apply, but you can recover only the remedies this agreement allows.

c. Limited Remedy. If Microsoft, or the device manufacturer or installer, breaches its limited warranty, it will, at its election, either: (i) repair or replace the software at no charge, or (ii) accept return of the software (or at its election the device on which the software was preinstalled) for a refund of the amount paid, if any. The device manufacturer or installer (or Microsoft if you acquired them directly from Microsoft) may also repair or replace supplements, updates, and replacement of the software or provide a refund of the amount you paid for them, if any. These are your only remedies for breach of warranty. This limited warranty gives you specific legal rights, and you may also have other rights which vary from state to state or country to country.

d. Damages. Except for any repair, replacement, or refund that Microsoft, or the device manufacturer or installer, may provide, you may not under this limited warranty, under any other part of this agreement, or under any theory, recover any damages or other remedy, including lost profits or direct, consequential, special, indirect, or incidental damages. The damage exclusions and remedy limitations in this agreement apply even if repair, replacement, or a refund does not fully compensate you for any losses, if Microsoft, or the device manufacturer or installer, knew or should have known about the possibility of the damages, or if the remedy fails of its essential purpose. Some states and countries do not allow the exclusion or limitation of incidental, consequential, or other damages, so those limitations or exclusions may not apply to you. If your local law allows you to recover damages from Microsoft, or the device manufacturer or installer, even though this agreement does not, you cannot recover more than you paid for the software (or up to $50 USD if you acquired the software for no charge).

e. Warranty and Refund Procedures. For service or refund, you must provide a copy of your proof of purchase and comply with Microsoft’s return policies if you acquired the software from Microsoft, or the device manufacturer’s or installer’s return policies if you acquired the software from a device manufacturer or installer. If you purchased stand-alone software, those return policies might require you to uninstall the software and return it to Microsoft. If you acquired the software pre-installed on a device, those return policies may require return of the software with the entire device on which the software is installed; the certificate of authenticity label including the product key (if provided with your device) must remain affixed. Contact the device manufacturer or installer at the address or toll-free telephone number provided with your device to find out how to obtain warranty service for the software. If Microsoft is your device manufacturer or if you acquired the software from a retailer, contact Microsoft at:

https://www.gnu.org/licenses/gpl-3.0.en.html

15. Disclaimer of Warranty.

THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
16. Limitation of Liability.

IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

https://www.apache.org/licenses/LICENSE-2.0

8. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages.

9. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability.

Mit gæt er at en dyppekoder med sådanne garantier vilel være usælgelig!!!!

larsp (15) skrev:

Hvis det bliver forbudt at bruge C, så er Linux smidt på porten. Det vil være et ret vidtgående krav. (og Windows, jeg ser at der er masser af C i Windows kernel)

Nyere OS er domineret af C.

Linux er C med en åbning mod Rust og en diskussion omkring C++.

Windows kernel og Win32 er C mens meget af det højere (OLE, COM, MFC etc.) er C++.

#17

Selv ældre OS er blevet meget C.

VMS 4.x (fra da jeg var ung) skulle være 1/3 Macro-32 (VAX assembler), 1/3 Bliss (DEC system language) og 1/3 alt muligt andet inkl. noget som ikke bør tælle som kode

VMS 9.x (idag) per optælling af maintainer 55% C, 30% Bliss og 15% Macro-32.

https://readwrite.com/the-nsa-list-of-memory-safe-...

Har en opdateret liste med sprog vurderet mere sikre.

Go
Rust
C#
Swift
Java
Ruby
Python
Delphi/Object Pascal
Ada

Jeg undrer mig lidt over listen.

C#, Java, Ruby og Python bliver som udgangspunkt ikke compilet til native og kan derfor ikke afløse C/C++ til alle opgaver.

Pascal og Ada var udbredte engang men er ikke populære idag.

Så er der Go og Rust tilbage.

(og Swift som jeg ikke kender meget til, men som jeg associerer med iPhone's og iPad's)

Herb Sutter (forfatter af nogle kendte C++ bøger, medlem af ISO C++ WG etc.) har skrevet et langt indlæg hvor han argumenterer for at C++ kan reddes.

https://herbsutter.com/2024/03/11/safety-in-contex...

Uanset om man er enig eller ej, så er hans skriv noget mere teknisk velfunderet end hvad de IT-sikkerheds myndigheder leverer.

Denne uge er det så SQL injection som er på agendaen:

https://www.ic3.gov/Media/News/2024/240325.pdf