6 ms·

The apparent fix: https://github.com/microsoft/omi/commit/4ce2cf1cb0aa656b8eb934c5acc3f4d6a6796bfa https://github.com/microsoft/omi/commit/4ce2cf1cb0aa656b8eb9.

by orf 5y ago

The apparent fix: https://github.com/microsoft/omi/commit/4ce2cf1cb0aa656b8eb934c5acc3f4d6a6796bfa https://github.com/microsoft/omi/commit/4ce2cf1cb0aa656b8eb9... Looks like a standard, absolutely gigantic C/C++ project that re-invents absolutely everything including an event loop, http server, XML parser, a C++ tool to generate C code to create a “str hash” implementation, a custom lexer for WQL and a parser for a “mof” file format. Still not clear on what it does. Seems safe.

the-dude 5y ago
But does it receive email? http://catb.org/jargon/html/Z/Zawinskis-Law.html http://catb.org/jargon/html/Z/Zawinskis-Law.html
jeffbee 5y ago
The "fix" doesn't include any tests that would indicate that it actually works. Doesn't seem like a very healthy project.
- rajamaka 5y ago
  The explanatory commit message of "Enhanced security" should be enough to document all you need to know!
  - cube00 5y ago
    You'd think a mention of the CVEs involved is mandatory for commits like these.
Cyph0n 5y ago
Looks like it’s mostly C, and not great C at that… In my humble opinion, this is a scary looking project.
- randomfool 5y ago
  Specifically- it appears to be mostly C99, lots of macros, lots of ugly buffer manipulation. But it's tooled for PREFast so you know it's secure! (https://github.com/microsoft/omi/blob/4ce2cf1cb0aa656b8eb934c5acc3f4d6a6796bfa/Unix/protocol/protocol.c#L193 https://github.com/microsoft/omi/blob/4ce2cf1cb0aa656b8eb934...) (j/k... I haven't seen that in ages). Guessing a port of MS's internal WMI codebase? This codebase just smells of rot all over.
  - pjmlp 5y ago
    That is why there is "Modern C", "Modern C++" as talked at conferences, blog posts and endless over here, and then real life code that we actually find out in production.
    - silon42 5y ago
      So the choice is RIIR or RIIC++ ?
      - pjmlp 5y ago
        It can also be RIIC#, RIID, RIIGo, RIIAda, RIIJava,... take your pick.
    - int_19h 5y ago
      I've seen and written plenty of modern (at the time of writing) C++ in production. It really depends on the team and the product.
      - pjmlp 5y ago
        Sure, yet this is the outcome from companies deeply involved in ISO, let alone those where regular folks don't even care HN exists.
        int_19h 5y ago
        Ironically, most modern C++ code I wrote was not for Microsoft, but a much smaller company that is not in any way involved in ISO C++ standardization process. It was due to that company culture - senior engineering leadership (which were also the founders) were all big standard C++ fans, and they wrote much of the original codebase. Large companies like MS often have codebases that are so ancient (e.g. HRESULTs and IF_ERR_GOTO type macros everywhere), they only get modernized very gradually if at all.
dralley 5y ago
> a standard, absolutely gigantic C/C++ project that re-invents absolutely everything including an event loop, http server, XML parser, a C++ tool to generate C code to create a “str hash” implementation, a custom lexer for WQL and a parser for a “mof” file format. This is the part that gets missed when people talk about "dependency inflation" re: Rust. Absolutely, it is a problem, but most C codebases of a sufficient size and vintage are vendoring some absolutely insane hidden "dependencies" that, on average, probably get a lot less testing and attention than the average package on crates.io. There are definitely risks with both approaches. https://wiki.alopex.li/LetsBeRealAboutDependencies https://wiki.alopex.li/LetsBeRealAboutDependencies
- capableweb 5y ago
  Not sure why what you're saying would be more true for C/Rust/JavaScript or any other language. The perverse idea of adding dependencies without actually reading through all the code you pull in exists in basically all language ecosystems, Rust included.
  - jstanley 5y ago
    In C it is much more inconvenient to include external dependencies, so it's much more common for people to roll their own implementations rather than using a tried-and-tested one.
    - xmaayy 5y ago
      Or copy in a .C/.h file that gets forgotten about, and therefore gets no security updates.
jerf 5y ago
Greenspun's law, "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." is really just a special case of a general principle. There's a lot of cases where if you use the wrong tool and/or don't know the right libraries, or don't or can't use them, or just won't, that you'll reinvent something that already exists, badly.
gsam 5y ago
CIM/WBEM goes all the way back to 1996. They essentially wanted a management infrastructure on all kinds of devices (including different architectures, so actually C made sense then), but that also notably included remote access. At the time, SOAP was still popular, so here we are with a rather silly transport protocol and all kinds of overhead reinventing things like SSH. However, the overall goal still makes sense, it was essentially a way of 'object'-ifying everything from logs to other metrics. This fit in with the overall mode of thinking in MS with DCOM and COM (and registry), and structured configuration/management. I'm sure it's paid massive dividends on Azure Linux infrastructure. For highly structured objects, SOAP and XML aren't a terrible fit, but I doubt many people would do the same thing again today. Honestly, they just needed to rewrite it in a safer stack. However, that still may not have saved them from all these vulnerabilities, given the scope of what they're implementing as remote management protocols. The relative scrutiny, fuzzing and manpower just hasn't been there, especially when it's obfuscated by various layers.
- onionisafruit 5y ago
  Not to take away from the rest of what you said, but I don’t think SOAP was _still_ popular in 1996. I don’t think it had become popular yet. I don’t think I even heard of SOAP before 1999 or 2000. I’m not a trend setter or anything, but if it was popular, I probably would have at least heard of it.
  - homarp 5y ago
    https://www.xml.com/pub/a/ws/2001/04/04/soap.html https://www.xml.com/pub/a/ws/2001/04/04/soap.html says SOAP was started in 98
  - gsam 5y ago
    That's fair, I was more speaking about XML and its use as a form of binary transport. Things like WS-Management and explicit SOAP obviously came a little bit later, and SOAP-like technologies were popularized for more general use in the 2000s. I think it's fair to say my experiences in general lean more towards observing standards groups.
pjmlp 5y ago
In typical Microsoft fashion, regardless of how much victories .NET and now Rust dev units achieve, the OS ones keep pushing for C and C++ no matter what. That is also why we now have WinRT, WinUI, Sphere OS, Azure RTOS, regardless of what Microsoft Security advises.

by orf 5y ago

the-dude 5y ago

But does it receive email? http://catb.org/jargon/html/Z/Zawinskis-Law.html http://catb.org/jargon/html/Z/Zawinskis-Law.html

jeffbee 5y ago

The "fix" doesn't include any tests that would indicate that it actually works. Doesn't seem like a very healthy project.

rajamaka 5y ago
The explanatory commit message of "Enhanced security" should be enough to document all you need to know!
- cube00 5y ago
  You'd think a mention of the CVEs involved is mandatory for commits like these.

Cyph0n 5y ago

Looks like it’s mostly C, and not great C at that… In my humble opinion, this is a scary looking project.

randomfool 5y ago
Specifically- it appears to be mostly C99, lots of macros, lots of ugly buffer manipulation. But it's tooled for PREFast so you know it's secure! (https://github.com/microsoft/omi/blob/4ce2cf1cb0aa656b8eb934c5acc3f4d6a6796bfa/Unix/protocol/protocol.c#L193 https://github.com/microsoft/omi/blob/4ce2cf1cb0aa656b8eb934...) (j/k... I haven't seen that in ages). Guessing a port of MS's internal WMI codebase? This codebase just smells of rot all over.
- pjmlp 5y ago
  That is why there is "Modern C", "Modern C++" as talked at conferences, blog posts and endless over here, and then real life code that we actually find out in production.
  - silon42 5y ago
    So the choice is RIIR or RIIC++ ?
    - pjmlp 5y ago
      It can also be RIIC#, RIID, RIIGo, RIIAda, RIIJava,... take your pick.
  - int_19h 5y ago
    I've seen and written plenty of modern (at the time of writing) C++ in production. It really depends on the team and the product.
    - pjmlp 5y ago
      Sure, yet this is the outcome from companies deeply involved in ISO, let alone those where regular folks don't even care HN exists.
      - int_19h 5y ago
        Ironically, most modern C++ code I wrote was not for Microsoft, but a much smaller company that is not in any way involved in ISO C++ standardization process. It was due to that company culture - senior engineering leadership (which were also the founders) were all big standard C++ fans, and they wrote much of the original codebase. Large companies like MS often have codebases that are so ancient (e.g. HRESULTs and IF_ERR_GOTO type macros everywhere), they only get modernized very gradually if at all.

dralley 5y ago

> a standard, absolutely gigantic C/C++ project that re-invents absolutely everything including an event loop, http server, XML parser, a C++ tool to generate C code to create a “str hash” implementation, a custom lexer for WQL and a parser for a “mof” file format. This is the part that gets missed when people talk about "dependency inflation" re: Rust. Absolutely, it is a problem, but most C codebases of a sufficient size and vintage are vendoring some absolutely insane hidden "dependencies" that, on average, probably get a lot less testing and attention than the average package on crates.io. There are definitely risks with both approaches. https://wiki.alopex.li/LetsBeRealAboutDependencies https://wiki.alopex.li/LetsBeRealAboutDependencies

capableweb 5y ago
Not sure why what you're saying would be more true for C/Rust/JavaScript or any other language. The perverse idea of adding dependencies without actually reading through all the code you pull in exists in basically all language ecosystems, Rust included.
- jstanley 5y ago
  In C it is much more inconvenient to include external dependencies, so it's much more common for people to roll their own implementations rather than using a tried-and-tested one.
  - xmaayy 5y ago
    Or copy in a .C/.h file that gets forgotten about, and therefore gets no security updates.

jerf 5y ago

Greenspun's law, "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." is really just a special case of a general principle. There's a lot of cases where if you use the wrong tool and/or don't know the right libraries, or don't or can't use them, or just won't, that you'll reinvent something that already exists, badly.

gsam 5y ago

CIM/WBEM goes all the way back to 1996. They essentially wanted a management infrastructure on all kinds of devices (including different architectures, so actually C made sense then), but that also notably included remote access. At the time, SOAP was still popular, so here we are with a rather silly transport protocol and all kinds of overhead reinventing things like SSH. However, the overall goal still makes sense, it was essentially a way of 'object'-ifying everything from logs to other metrics. This fit in with the overall mode of thinking in MS with DCOM and COM (and registry), and structured configuration/management. I'm sure it's paid massive dividends on Azure Linux infrastructure. For highly structured objects, SOAP and XML aren't a terrible fit, but I doubt many people would do the same thing again today. Honestly, they just needed to rewrite it in a safer stack. However, that still may not have saved them from all these vulnerabilities, given the scope of what they're implementing as remote management protocols. The relative scrutiny, fuzzing and manpower just hasn't been there, especially when it's obfuscated by various layers.

onionisafruit 5y ago
Not to take away from the rest of what you said, but I don’t think SOAP was _still_ popular in 1996. I don’t think it had become popular yet. I don’t think I even heard of SOAP before 1999 or 2000. I’m not a trend setter or anything, but if it was popular, I probably would have at least heard of it.
- homarp 5y ago
  https://www.xml.com/pub/a/ws/2001/04/04/soap.html https://www.xml.com/pub/a/ws/2001/04/04/soap.html says SOAP was started in 98
- gsam 5y ago
  That's fair, I was more speaking about XML and its use as a form of binary transport. Things like WS-Management and explicit SOAP obviously came a little bit later, and SOAP-like technologies were popularized for more general use in the 2000s. I think it's fair to say my experiences in general lean more towards observing standards groups.

pjmlp 5y ago

In typical Microsoft fashion, regardless of how much victories .NET and now Rust dev units achieve, the OS ones keep pushing for C and C++ no matter what. That is also why we now have WinRT, WinUI, Sphere OS, Azure RTOS, regardless of what Microsoft Security advises.