back to article Killer ChAraCter HOSES almost all versions of Reader, Windows

Get patching: Google Project Zero hacker Mateusz Jurczyk has dropped 15 remote code execution vulnerabilities, including a single devastating hack against Adobe Reader and Windows he reckons beats all exploit defences. The accomplished offensive security researcher (@j00ru) presented findings at the Recon security conference …

  1. Paul Crawford Silver badge
    FAIL

    Adobe (and I guess MS as well) put font handling in the kernel from NT 4.0 to gain speed at the expense of having privileged-based protection, and against Dave Cutler's original micro kernel plans. What could possibly go wrong?

    Oh yes, this...

    1. Sean Timarco Baggaley

      As opposed to, say, game controller drivers? Or did you not read the article about the latest Linux kernel release?

    2. Anonymous Coward
      Anonymous Coward

      Um, font handling is graphics-related, and yes, graphics drivers are in the kernel for performance reasons since performance gaming demands less context switching. Not all of us use cutting-edge hardware, remember.

  2. Mystic Megabyte
    Facepalm

    Ooops!

    That is some powerful bug, I'm so glad that I moved away from Windows some years ago. If the BBC would stop using Flash I would not need Adode's products either.

    I'm not being smug, Windows stops being productive when you spend more time fixing it than using it.

    1. Anonymous Coward
      Anonymous Coward

      Re: Ooops!

      doesn't take long, just remove adobe reader

      1. Danny 14

        Re: Ooops!

        ironically enough, when office 2013 came out we got rid of adobe reader and used word to open PDFs (mainly so the teachers can edit PDFs as appropriate). Only the drama and music teachers have adobe reader on a couple of machines due to various locked down PDFs for manuscripts and scores.

  3. hplasm
    Devil

    Compared to this...

    Heartbleed? Tis but a fleshwound.

    1. kryptylomese

      Re: Compared to this...

      Good try but you do not have to use openssl on Linux as there are alternatives. Also because it is opensource, you can fix it yourself rather that waiting on Microsoft to decide whether to fix something or not.

      1. Crazy Operations Guy

        Re: Compared to this...

        "Also because it is opensource, you can fix it yourself"

        I am a staunch supporter of Open Source, but I have to say that arguments like this help no one and only serve to ruin the image of Open Source in the people's minds when they find out what is involved to "fix it yourself". That argument just alienates people that would otherwise love Open Source because they have neither the time nor skills nor inclination to write and/or apply patches to random pieces of software.

      2. Sean Timarco Baggaley

        Re: Compared to this...

        Good try, but expecting amateurs to fix industrial strength cryptography code is a bit much. I understand the principles involved, but none of the maths.

        Still, ignorance doesn't appear to be a barrier to some coders, or the Heartbleed issue wouldn't have happened.

        1. Anonymous Coward
          Anonymous Coward

          Re: Compared to this...

          But it worked so well for Debian!

        2. Peter Gathercole Silver badge

          Re: Compared to this... @STB

          The counter to this is that although you (and I, I will admit) may not have the skill to fix problems like this, we do have the ability to aid someone who does, with a formal or informal contribution of either money or equipment, and it does not even have to be the developer with the Open Source software model.

          I suppose that you could give Microsoft and Adobe money and ask them to do the same, but I suspect that it would disappear into the general coffers, and not significantly affect the quality of the code.

          1. Sean Timarco Baggaley

            Re: Compared to this... @STB

            A "formal or informal contribution of either money or equipment" = payment. No matter how you try and frame it, it comes down to offering something in return for a service.

            The bugs in question have been sitting in multiple versions of Windows and Adobe's software for well over a *decade*, yet it took Mateusz Jurczyk—a professional hacker—to find them. Are all programmers the world over supposed to be able to match Mr. Jurczyk's abilities as a matter of routine?

            Even if I had the entire source code to Windows, OS X, and the latest spin of Gentoo sitting on my hard disk, I wouldn't have the faintest idea where to even *start* looking for backdoors and the like, let alone how to fix them if I came across one. My current expertise lies in writing tutorials about flinging sprites around a screen using C# and Unity, not in untangling the source code to OpenSSL. And I once spent 15 solid months doing nothing *but* debugging other people's code, so thanks, but no thanks; I'll leave that to hardcore masochists.

            Yes, it means trusting businesses, but how is that any different to trusting random folk on the Internet? I'm not wealthy enough to have money to throw at random strangers whose CVs could be complete and utter fabrications for all I know. When it comes to programmers with security skills, performing due diligence isn't optional.

            So, I can just as easily have Apple, Microsoft, etc. "fix their source code" instead, with no need for me to have access to it. Better still, I actually get free, and (usually) timely patches and updates from both companies without having to lift so much as a finger!

            I believe the current fashion among young whippersnappers is to add a "W3wt!" at this point, or something equally vacuous.

            1. Richard 12 Silver badge
              Facepalm

              Re: Compared to this... @STB

              You've missed the point - but to be fair, so did the OP.

              Finding exploits doesn't require the source code, but fixing exploits does.

              It's also much easier to fix an exploit than to find one. Eg a use-after-free

              Once an exploit is found, there are two scenarios:

              A) Closed-source software. Only the organisation that owns the software can choose to spend the resources to fix it.

              B) Open-source software. Any entity can choose to spend the resources needed to fix it.

              If you depend on that software, then under (A) you can request that the owner fixes it. If they do not, then you can either stop using the software or live with the consequences of the exploit.

              Under (B), you can request that the organisation that made it fixes it. If they do not, then you can arrange for somebody else to fix it.

              Under (A), if the entity that owns it has lost the source code or closed down, you are done for.

        3. Michael Wojcik Silver badge

          Re: Compared to this...

          Good try, but expecting amateurs to fix industrial strength cryptography code is a bit much. I understand the principles involved, but none of the maths.

          The only maths needed to understand or fix Heartbleed is basic arithmetic. It's a read past the end of an array.

          The hard part about Heartbleed was finding it - and even that shouldn't have been hard, if the commit had been reviewed in the first place, or if anyone was fuzzing new OpenSSL features as they were added.

          Heartbleed happened because:

          1) The code in question was written by a typical C programmer, i.e. one who prefers ad hoc, terse, poorly-structured code to the carefully considered and properly-designed sort. In that it matches the rest of the OpenSSL source base. I have much respect for Eric Young and Steve Henson, for their technical accomplishments and knowledge, but the fact is that their code is an ugly mess. As is most of the C I've seen (and I've been working with the language since the mid-80s).

          2) The DTLS Heartbeat code wasn't properly reviewed when it was submitted. That may be partly because it was written by the author of the spec; it's probably mostly because the OpenSSL team was badly understaffed and undercompensated at the time. But this is what happens when you accept patches without thorough review.

          3) Despite OpenSSL's widespread use, no one tested the feature thoroughly when it was added - at least no one interested in publishing the vulnerability. OpenSSL is widely used, but mostly because people need to tick off a "secure communications" checkbox. It's used grudgingly, not because it makes anyone's life easier. And so people don't want to test it. They just hope it works.

          Once Heartbleed was announced, it was quite easy to identify the mistake, and fixing it was trivial.

      3. hplasm
        Facepalm

        Re: Compared to this...

        "Good try but ..."

        I think you need to read it again, perhaps?

        Compared to this, Heartbleed IS but a fleshwound...

        /whoosh

  4. getHandle

    Will it BLEND?

    Yes, I guess so :-)

  5. Destroy All Monsters Silver badge
    Thumb Up

    His Kung-Fu is the best

    It's like getting owned by Hacky Chan!

    1. Richard 26
      Facepalm

      Re: His Kung-Fu is the best

      I just realized I opened a PDF link about a Reader exploit.

      1. big_D Silver badge
        Facepalm

        Re: His Kung-Fu is the best

        That was my first thought as well.

        PDF is dangerous, read this PDF to find out why! P4WN3D!

  6. This post has been deleted by its author

    1. Voland's right hand Silver badge

      Welcome to the last 20 years of software development

      I have yet to see a _SINGLE_ large corporation where "reliability and security" of the developer's code is fed back into his rating.

      It is actually trivial - the source code control system can trace a particular commit to a particular person - that should go automated on his current perf review regardless of how old is the code in question. In reality - it never does.

      1. Anonymous Coward
        Anonymous Coward

        Re: Welcome to the last 20 years of software development

        To be effective, you would also need the chain of decisions that led to that particular "problem." Typically that only occurs when a truly catastrophic event occurs. (Aircraft crashes, Shuttle blows up, bridge collapse, ....) You can fire everyone over a period of time and still have the problem found in the management side that forces the situation in the first place.

        BTW, I like including tolerances (sanity checks) even in software. If something is passed into my design that is unexpected, there's certainly a problem. Notify the operator and make damned sure that this is really the intent. It's the same order as not crossing a bridge under certain conditions (wind, earthquake, ...).

  7. Andy The Hat Silver badge

    PDF was originally touted as providing access to a secure document. Standard, reliable and secure. Since then, however secure the document, the apps break the system around them.

    Bit like locking the riveted steel front door on the way out but breaking the kitchen window ...

    1. Crazy Operations Guy

      Funny how that works...

      Lately I've been considering just converting my documents to Bitmaps and send those to people... At least we know that those are secure (or at least should be since reading a bitmap and drawing it on the screen is the graphics library equivalent of "Hello World")

      1. Anonymous Coward
        Anonymous Coward

        Should be secure, but aren't necessarily. There's been a slew of security patches for various bitmap loader libs this year. (PNG anyone?) Much better odds than PDF though.

        Open-src font libs are also potentially vulnerable to similar attacks, and the PDF readers on Linux... yeah they've got major problems too.

  8. John Smith 19 Gold badge
    Unhappy

    Does anyone think he's really the first person to have discovered these?

    In a very secure office somewhere in Maryland....

    "That sneaky little f**ker has f**ked us good. Now we'll have to find more ways in that most people haven't thought of. We've been using those for decades. Ba***rd."

    1. Anonymous Coward
      Anonymous Coward

      More likely

      "Ha! That sneaky little f**ker has only found 15 of 'em."

  9. John G Imrie

    Does this also ...

    Effect BSD and Linux font rendering or is it purely a Micosoft problem?

    1. Anonymous Coward
      Anonymous Coward

      Re: Does this also ...

      "Effect BSD and Linux font rendering or is it purely a Micosoft problem?"

      Unlikely since X.org is (almost?) entirely source. However AFAIK a lot of it still runs with root privs so in theory a similar exploit could exist.

      1. Tomato42
        Linux

        Re: Does this also ...

        actually, you can have rootless X for some time now, dunno how many distros default to that

    2. Anonymous Coward
      Anonymous Coward

      Re: Does this also ...

      While X is safely outside the kernel where is should be, I think the Linux kernel still has some font handling stuff for the console, RHEL certainly passes in font arguments into the kernel by default, I guess the driver for the graphics card needs some.

      SYSFONT=latarcyrheb-sun16

      I tend to rip this out as graphics heads are well into the realm of fishes with bicycles IMHO when it comes to servers, but it seems I'm in a minority.

      1. MacroRodent

        Re: Does this also ...

        The font handling in Linux kernel is trivial, just fixed-width bitmap fonts. Should be easy to check.

    3. Crazy Operations Guy

      Re: Does this also ...

      Some graphics drivers have routines to accelerate rendering text on the screen, so there might be something lurking in there. And there is a good chance that there is some Adobe-written code in there as well...

  10. Anonymous Blowhard

    Quote from Wikipedia:

    "Adobe, the Spanish word for mud brick originates from Arabic, is a building material made from earth and often organic material."

    I think "organic material" is a euphemism for "shit".

    1. Omgwtfbbqtime
      Coat

      Re: Quote from Wikipedia:

      I always thought adobe meant "half baked"

      Thank you, I'll be here all week.

    2. dogged
      Headmaster

      Re: Quote from Wikipedia:

      I like the way you think but actually it's "straw".

      1. hplasm
        Happy

        Re: Quote from Wikipedia:

        "I like the way you think but actually it's "straw"."

        Mostly horseshit then?

  11. joed

    all suported versions of Windows

    does XP count?

    1. Dan 55 Silver badge
      Holmes

      Re: all suported versions of Windows

      Maybe if you flip the POSReady switch in the registry?

  12. TeeCee Gold badge
    Facepalm

    Ah. Adobe. Again.

    Not for the first time do I wish that Windows had ceased support for Adobe fonts when TrueType was introduced.

    I suppose that, with the benefit of hindsight, embedding Adobe's crapware in your O/S and giving it kernel privilege always was a one-way ticket to fuckup city.

    1. Crazy Operations Guy

      Re: Ah. Adobe. Again.

      That the problem with deciding between "Increase security just a bit" and "substantially improve performance"... While the performance hit is fairly trivial nowadays, there was never a reason to change it. Users demand things be fast and pretty, they don't care about security...

    2. Ken Hagan Gold badge

      Re: Ah. Adobe. Again.

      The amazing thing is, MS have completely re-written all of Windows from the ground up at least twice since this bug came in and they've managed to inadvertently re-introduce the flaw on each occasion.

      1. Captain DaFt

        Re: Ah. Adobe. Again.

        "MS have completely re-written all of Windows from the ground up at least twice since this bug came in"

        At Microsoft, copy and paste is considered a rewrite.

      2. Michael Wojcik Silver badge

        Re: Ah. Adobe. Again.

        MS have completely re-written all of Windows from the ground up at least twice since this bug came in and they've managed to inadvertently re-introduce the flaw on each occasion.

        No they haven't. They've significantly rewritten large parts of Windows, but they haven't "completely re-written all" of it. There's still plenty of old code. It's absurd to believe that even the big Windows rearchitecting moments involved rewriting every single line of code.

        That's why ATMFD.DLL still has a copyright date that starts with 1993.

        And, of course, ATMFD.DLL has a copyright notice that says it belongs to Adobe. They wrote it. Microsoft just sticks it in Windows.

  13. Tom 7

    Baffled

    as to why the Linux kernel would even be bothered with fonts - given that the kernel gives no fucks about graphics at all.

    1. Anonymous Coward
      Anonymous Coward

      Re: Baffled

      Have you not heard of KMS?

      1. Anonymous Coward
        Anonymous Coward

        Re: Baffled

        @s2bu

        KMS has bugger all to do with font parsing in the Linux Kernel.

    2. storner

      Re: Baffled

      Some of us old grey-beards do like to read stuff on the console, which requires a working font.

      Especially when you live in a country where ASCII is only a subset of the alphabet.

      1. Michael Wojcik Silver badge

        Re: Baffled

        Some of us old grey-beards do like to read stuff on the console

        That's why I only use a hard-copy terminal. I go through a hell of a lot of fan-fold, particularly when the browser refreshes, but it's worth it for the safety.

  14. Rolf Howarth

    "Adobe again"

    "There's a new exploit found in software developed by X. X is crap, I hate X, it's a virus, I can't wait to remove it from my computer." Blah blah blah. For X substitute Microsoft, Apple, Adobe, Oracle, Google, Java, etc.

    I've read that so many times on the Reg forums that it's getting a little bit boring! Find me any large software product that's been around for a while from any manufacturer that doesn't have bugs in it (or which isn't doing "unethical" stuff like infringing your privacy or charging you for things you think ought to be free).

    Open source isn't the answer either. First, you can guarantee there'll be tons of old unpatched versions of libraries still being used long after a fix may have been checked in the repository. But most of all, you can bet your bottom dollar that there are lots of well funded teams of developers in places like China, North Korea, Israel, NSA, and elsewhere who are poring over obscure open source code looking for exploits, and not reporting them when they find them. The fact that they have the source code only makes their job easier!

    No one should be complacent, but mindlessly bashing manufacturers and developers just for the sake of it isn't being particular clever or contributing to the debate.

    1. Anonymous Coward
      Anonymous Coward

      @ Rolf Howarth - Re: "Adobe again"

      Yes, because any imbecile can write code and they surely do. Just try to figure out what will come out of the initiatives to forcefully teach coding in US schools.

    2. Michael Wojcik Silver badge

      Re: "Adobe again"

      I've read that so many times on the Reg forums that it's getting a little bit boring! Find me any large software product that's been around for a while from any manufacturer that doesn't have bugs in it

      I've read that so many times on the Reg forums that it's getting a little bit boring.

  15. James Cane

    C

    Yet another vulnerability caused by the p1ss-poor design of C. Specifically, its total ineptitude in dealing with strings.

    I do wonder how much more secure the world's computing infrastructure would be if C had been given a strong string type from the beginning.

    1. Dan 55 Silver badge
      Meh

      Re: C

      It's not difficult to use strings on C, you just need to remember how pointers work and not to use the obsolete stdlib string-write functions which take a pointer but don't take a maximum length.

      If you can't cope with that then obviously you shouldn't be writing kernel code in the first place... as Adobe shouldn't be. Or any other code for that matter.

      1. James Cane

        Re: C

        Dude, I know how to use strings in C. But your argument essentially boils down to security through trust, rather than security through engineering. And hence we find ourselves in the mess we're in.

        It's all very well to say that you shouldn't be writing kernel code if you're not good enough, but the fact is that clearly that doesn't happen in real life. Partly because Windows has a driver model which often requires kernel code to be written by third parties, but mostly because human beings are human beings.

        If the aircraft industry had this approach to safety, planes would fall out of the sky. The trick with safety is to recognise when a policy isn't working and change it. The policy of trusting developers to be good and never make mistakes isn't working.

        1. Dan 55 Silver badge

          Re: C

          C is a language which compiles easily into assembly language and lets you shoot your foot but trusts you to do the right thing. With this in mind it might be right for kernels following best coding practice and code review but it's obviously wrong for the aircraft industry.

          The failure was the development methodology or maybe even choosing C in the first place if the developers weren't up to it. Maybe Pascal might have been a better choice, indeed a lot of the old Windows API was Pascal orientated. Then again Adobe would probably been able to shoot their own foot in Pascal too.

          As for the aircraft industry, the code should be formally proven instead of banged out.

          But criticising C is not helpful and unproductive, because everybody knows what they get and they don't get if they choose C and first and foremost they don't get nice strings. C's pros outweigh its cons, that's why it's still about.

          1. James Cane

            Re: C

            I'm not saying anything about whether the aircraft industry should or shouldn't use C. I was making an analogy. Addressing the meta-problem, if you like.

            I'm saying that the aircraft industry has an approach to safety which assumes that people are flawed and that mistakes happen, and the best approach to safety is to treat human fallibility as an engineering problem.

            The software industry has an approach to safety which assumes that engineers are daredevil heroes, and the answer comes from individual developers "doing the right thing". This clearly fails.

            I don't have a problem with C in general, but the string handling is such a massive issue. It's not a small thing - it's huge. Almost all of the code vulnerabilities that are found and exploited come from this one thing. Not quite all of them, but pretty damned close.

            1. Dan 55 Silver badge

              Re: C

              "The software industry has an approach to safety which assumes that engineers are daredevil heroes, and the answer comes from individual developers "doing the right thing". This clearly fails."

              It does if they are working as isolated units. But there are stages before and after the programming stage, or there should be.

          2. Peter Gathercole Silver badge

            Re: C @Dan 55

            If you were using ISO standard Pascal (ISO 7185), it may have made for safer code, but in order to achieve that safety, you had to put up with a language that was so limiting that doing something like writing an OS would have been a virtual impossibility.

            I mean, really. ISO 7185 Pascal does not have anything remotely like a pointer. It also does not have any way of addressing data objects that have not been declared. It's also pretty difficult to handle variable length records in data files, because of the inflexible nature of the I/O system.

            So what happened is that you got things like Turbo Pascal and Delphi, which were not Pascal, and introduced enough of the methods needed to write systems, which also added some of the same vulnerabilities that C had.

            You should have used something like Ada as a counter to C, not Pascal. Although Ada was a strongly typed language, it's very reason for being was to write correctly coded systems for such things as military application, so it had the necessary constructs to interface with hardware.

          3. Anonymous Coward
            Anonymous Coward

            Re: C

            Windows APIs were never ' Pascal-oriented'. They just used 'Pascal' default calling convention, because it was a little faster and smaller (stack is setup by the called function, a single RET clears also the stack) than the default C calling convention. But Windows is a C OS designed to be used by C applications using C data types.

            Anyway, being a low level language doesn't mean you can't have a string type properly managed. Pascal has pointers like C, and despite the lack of curly braces, compiles easily into assembler too. Heck, even the x86 assembly has instructions designed with string manipulation in mind!

            String are an essential part of computing, and C stubbornly refusing to acknowledge it was and is just arrogance. I can understand if it was FORTRAN, but not a much more general purpose language.

        2. Peter Gathercole Silver badge

          Re: C @James Cane

          Unless you're prepared to have massive inefficiencies in your code (like surrounding all data structures with hardware write protected regions), it's always going to be a matter of trust.

          If you use a language that does strong boundary and type checking for all data objects in software, you're trusting that the compiler and/or run-time is correct, and does not contain any flaws You're also always going to find that your code runs slower with these checks.

          I'm not going to suggest that there are not sound reasons to stop using C, but using a language with better protection does not guarantee total safety.

          C is still excellent for what it was written for, generating code that closely fits with the underlying computer architecture. But it's not a perfect language, by any means.

          When C was first developed, it was necessary to have a language that would map very closely to the system ISA (and it did map to the PDP11 instruction set very nicely), because even minor inefficiencies in code size may have pushed the kernel beyond the 56KB address space on a non-separate I&D PDP11 (I used to run a PDP11/34A, and had different kernels to drive all of the terminals without a tape drive, or to have only some of the terminals working with the tape driver compiled in). IIRC, Sun 3 680x0 systems had to have a kernel less than 1MB.

          That time is fortunately past, but that does not mean that in these days of a word-processor needing 100's of megabytes of memory just to load, that aspiring to produce efficient code should not be something to strive for.

          1. James Cane

            Re: C @James Cane

            Of course it wouldn't guarantee total safety. What does? This argument is like saying that you shouldn't put railings on bridges because it's still possible to fall over.

            Not using C would provide a much higher level of comfort. Of course, we have a legacy code issue and that's not going away.

            I agree that efficient code is worth striving for, but in this day and age, secure code is far more important than getting every last drop of performance. I'm not suggesting we suddenly go to Javascript, just that it's a shame that the C language spec never included strings.

        3. Ken Hagan Gold badge

          Re: C

          "But your argument essentially boils down to security through trust, rather than security through engineering."

          Actually it didn't. He was quite clear that you can avoid the problem by avoiding the functions that don't take a maximum length. (Truncation brings other problems, but they are more subtle and much less likely to lead to a stack-trashing exploit.) Avoiding a relatively small set of library functions is an engineering problem. The Microsoft compiler will happily flag any and all uses of the offending set and you can write your makefiles so that such code does not build.

          Curiously enough, Microsoft's own secure-coding processes, introduced with much fanfare around the time of XPsp2, do exactly that, which makes it all the more mysterious that this kernel code managed to get through the safety net. What's the betting that the handling of Adobe Type 1 fonts gets a special exemption from modern coding standards on the grounds that it seems to work, no-one has touched it for a decade and no-one wants to?

          Also, what's the betting that MS now delete the offending code from Win10 and roll out a "security hotfix" for all supported releases (That may or may not include Server 2003.) that simply disables Type 1 support from all supported versions of Windows, forever?

          1. Dan 55 Silver badge

            Re: C

            And better than the truncating functions, you can use the allocating functions. Something like asprintf does all the magic for you and returns a pointer to the string.

          2. Anonymous Coward
            Anonymous Coward

            Re: C

            "Also, what's the betting that MS now delete the offending code from Win10 and roll out a "security hotfix" for all supported releases (That may or may not include Server 2003.) that simply disables Type 1 support from all supported versions of Windows, forever?"

            They can't. OpenType, which Microsoft actively supports, can have Type 1 data in it.

          3. John Smith 19 Gold badge
            Unhappy

            @Ken Hagan

            "Curiously enough, Microsoft's own secure-coding processes, introduced with much fanfare around the time of XPsp2, do exactly that, which makes it all the more mysterious that this kernel code managed to get through the safety net. What's the betting that the handling of Adobe Type 1 fonts gets a special exemption from modern coding standards on the grounds that it seems to work, no-one has touched it for a decade and no-one wants to?"

            Indeed much fanfare on that re-write.

            You do have to wonder how deep it went.

        4. Anonymous Coward
          Anonymous Coward

          Re: C

          "If the aircraft industry had this approach to safety, planes would fall out of the sky. The trick with safety is to recognise when a policy isn't working and change it. The policy of trusting developers to be good and never make mistakes isn't working."

          Under THAT standard of thinking, compilers would be considered munitions and subject to Big Brother levels of scrutiny. I believe someone wrote a paper on that in the distant past.

          Oh, and BTW, planes still DO fall out of the sky, sometimes through no fault of anyone involved in the process, so under your thinking, the process currently in place isn't working. OR...the chaotic nature of the universe means, no matter what we do, crap happens. If there's nothing you can do to stop or even mitigate it, all we can do is roll with the punch, and if the inevitable threat happens to be existential, well...nice knowing you...

      2. James Cane

        Re: C

        Or to put it another way, what you say is both totally correct and completely missing the point.

      3. Captain DaFt

        Re: C

        Doesn't matter how good the language or programmer is if the word from on high is, "You'll have this code ready to ship tomorrow, or I'll find someone that can!"

        1. Anonymous Coward
          Anonymous Coward

          Re: C

          "Doesn't matter how good the language or programmer is if the word from on high is, "You'll have this code ready to ship tomorrow, or I'll find someone that can!""

          Then you tell the guy on high that anyone that can do as claimed will be a legal liability for the whole company and that you'll inform the legal department of the demand. Since they have to answer to regulators, they're the one department that can exert influence on the Board.

    2. Anonymous Coward
      Anonymous Coward

      @James Cane - Re: C

      Don't expect a programming language to compensate for missing skills. Better than that, don't write code if you don't know what you're doing.

      1. Anonymous Coward
        Anonymous Coward

        Re: @James Cane - C

        "Better than that, don't write code if you don't know what you're doing."

        Ever heard the phrase, "A little knowledge can be dangerous"? It only takes a little knowledge for a programmer to think he knows what he's doing, and with self-reinforcement, he'll naturally take that to knowing that he knows what he's doing and that everyone else is just jealous.

        As for formal proofing, that is such a difficult thing to spell out that the only OS known to be formally proved is a microkernel, and that is only on the assumption no device has DMA access, which imposes a performance penalty, and yes, there is a need for performance in certain areas.

  16. John Smith 19 Gold badge
    Unhappy

    Let's see if I've got this straight

    C is dangerous because of it's memory handling.

    C is powerful and flexible because of its memory handling.

    Bad developers shouldn't write operating systems.

    Bad developers do write operating systems.

    Pascal is a poor model for secure OS writing as it's not got enough features to write an OS.

    Now let me remind people of a few bits of history.

    C was developed to allow Unix and other system apps to be written easily in a time of constrained resources both on the hardware to be supported and the compiling process itself (although I think the DEC Proprietary language "Bliss" was better at optimization it retained the single data type "word" and everything had to built on top of that. Not fun).

    C was written by and for the staff at Bell Labs, who included some of the best software developers in the world. Key apps for them included the software to control the US telephone exchanges. This must be reliable.

    Nicholas Wirth did not write an OS in Pascal. He and his team at ETH did write an OS in follow on languages Modula 2 (for Lilith workstation) and A2 for the Oberon language. Embedded development could be done on Turbo Pascal because it supported access to the whole memory and IO address space as 2 special arrays with no safety net of any kind.

    Ada was specifically written to support real time embedded software development. AFAIK most of the 20 000 different languages the DoD supported, a statistic that got DoD in getting "1 language to rule them all" (to coin a phrase) were assembler languages, followed by things like Jovial, developed exactly for those functions.

    But Ada's design-by-committee design stuffed everything but the kitchen sink in and made compiler development a royal PITA.

    And all (except Bliss, which is contemporary) were developed after C. A live compiler on the terminal beats a dead tree standard any day. :-( .

    The automotive and other industries (medical products IIRC) do have secure C coding standards.

    They typically work by assigning all the necessary memory at start up. From then on everything is static allocated.

    C & C++ are very powerful. But do you need that power? My experience of embedded was a lot of the time it was "write a hex value to this location and read something at this location."

    On that basis being able to specify (at some level in the language) specific hardware addresses (with a bit of in line assembler) were the key needs for those functions.

    1. Dan 55 Silver badge

      Re: Let's see if I've got this straight

      What are pointers but operators which read and write values to/from locations?

      Then there's the memcpy or strcpy functions which takes a location and an array of bytes to write and uses a loop to copy the array to the location, and instantly people who didn't take care started shooting themselves in the foot. If we remove the memcpy() and strcpy() functions then people will write their own looping functions which will also screw up.

      Remove malloc() because it's too powerful and people forget to free() and guess what happens, people will declare fixed-length statically allocated byte arrays instead and then then happily overflow them or get the scope wrong anyway.

      So if we remove fixed-length static arrays there'll still be another way to shoot yourself in the foot, probably involving structs.

      You could overhaul C into some bureaucratic thing like Java where every object has to be stamped in triplicate and there's a huge library which does everything for you and you might think that you've successfully stopped the foot shooting... except you haven't because there are still Tomcat websites which barf Java stack traces over several pages.

      The problem's not the language, especially in C's case where it's a concise enough language that you can claim to know completely, warts and all. C++ isn't knowable by one person but then again it's got RAII which is a great way of stopping you shooting yourself in the foot.

  17. Sean Timarco Baggaley

    Microkernels vs. Monolithic kernels...

    I seem to recall that microkernels were the in thing during the 1990s, but this predates the recent rise of cheap multi-core CPUs. (There were some high-end specialist CPUs that had multiple cores, but they weren't found in computers most of us could actually afford.) Today, even the Intel Atom x7 range comes with up to four cores as standard.

    Could the microkernel architecture be more viable on today's multicore CPUs? Running *multiple* microkernels in parallel might also be an alternative, with each dedicated to a particular set of tasks. Just because UNIX and Windows have followed the traditional path of loading everything onto the shoulders of a single kernel, it doesn't follow that this is the way it *must* be done forevermore.

    The above is why I get irritated by the focus on irrelevancies like Open Source and Software Libre. Not that they don't have their uses, but they've distracted the industry and led us down the path of a de-facto architectural duopoly: it's either Windows, or some flavour of UNIX. Windows' current kernel is a relatively recent design, but UNIX is getting on for 40 years old and still has neck-bearded lunatics gibbering on about 'human-readable' config files*.

    The monolithic kernel design is inherently compromised as it puts all our eggs in one basket. Break just one of those eggs and the entire basket gets messy fast. Yet there is no mainstream OS architecture that doesn't follow this model. Windows, GNU/Linux, most BSD flavours, Android, iOS, and so on are all tied to this design.

    This cannot be healthy for the long-term future of the industry.

    Time for my dried frog pills, I think.

    * I don't know what makes a text editor so special that it doesn't count as a dedicated file reader given that text is stored as numbers, just like everything else. Nor do I understand the fixation on storing config data in a format that usually *requires* the reader to be fluent in English. What's the bloody *point* of computers when you're going out of your way to make life *harder* for their users? But I digress.

    1. Charles 9

      Re: Microkernels vs. Monolithic kernels...

      The main reason microkernels aren't used is performance, especially in things like graphics where you may be interacting user-mode apps with kernel-mode drivers many times a second. Microkernels try to shove everything nonessential into user space, but what's considered "nonessential" differs from application to application. Take SeL4, the only kernel to have a formal proof. It contains a caveat; this proof assumes no device has Direct Memory Access. Now take performance gaming and GPGPU applications. To make the most out of these applications, you need DMA both ways. So you end up with a dilemma. You can make the place tighter than Fort Know, but that means lots of hoop-jumping that irritates users. Irritated users start looking for shortcuts. Meanwhile, there's continual demand for performance which demands streamlining. How do you balance performance with security?

      FTR, most kernels in use today are hybrid kernels (this includes NT and Linux): trying to find that balance between security, performance, and modularity.

  18. Howard Hanek
    Pirate

    Solution

    The solution is obvious. Round up all the type face foundry people and torture them until they confess.......

    Why would anyone name their company after a neolithic architectural style anyway? Must be something wrong there.....

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like