Skip to content
DevMeme
4320 of 7590
Security Post #4722 · source on Telegram

Defense In Depth, Geopolitics Edition

Description

A simple network diagram shows traffic flowing by a dotted arrow from a blue cloud labeled "The Bad Internet" through four brick firewall icons into a blue bubble labeled "Our trusted LAN." The firewalls are labeled "Huawei FW" with "Protection against US backdoors," "Juniper FW" with "Protection against Chinese backdoors," "Cisco FW" with "Protection against Israeli backdoors," and "Checkpoint FW" with "Protection against Russian backdoors." A small t.me/dev_meme watermark appears near the lower-left corner. The joke is a cynical defense-in-depth model where each security appliance is trusted mainly to defend against the geopolitical backdoors suspected in the previous vendor.

Comments

139
Anonymous ★ Top Pick The threat model is solid until procurement asks which nation-state backdoor comes with the best enterprise discount.
  1. Anonymous ★ Top Pick

    The threat model is solid until procurement asks which nation-state backdoor comes with the best enterprise discount.

  2. @SamsonovAnton 4y

    And all of those firewall appliances built upon US / UK designed processors. 👌

    1. dev_meme 4y

      so network traffic will travel through CPU?

      1. @SamsonovAnton 4y

        Unlike switches with ASICs, firewalls process traffic by software in a general-purpose CPU, with some offloading / acceleration possibility.

        1. dev_meme 4y

          Well how? Will network traffic ever go below the kernel? CPU processes 0s and 1s, and doesn't do anything else. How will a CPU accelerate the network or provide firewall capabilities? If you're talking an HSM kinda thing or some chip with a compiler burned as firmware, it's different.

          1. no name 4y

            see uefi rootkit

            1. dev_meme 4y

              see what? A rootkit injects some modules to the host, and again it works at the kernel level, not CPU level. A CPU is there to process 0s and 1s. A CPU is a large number of transistors to process 0 or 1 i.e. current flowing or not.

              1. no name 4y

                i mean it is possible to inject something sneaky by patching higher levels

                1. dev_meme 4y

                  It's totally possible and I have both created rootkits and mitigated them from systems, but it has nothing to do with the CPU doing that stuff.

              2. @SamsonovAnton 4y

                Modern and complex CPUs like x86 and ARM are "computers in itselfs" that can do much more than simply running the supplied code — they may act as remote controllers. (Some of those functions may lie in an external chip, but still tightly coupled to the central processing unit.)

                1. dev_meme 4y

                  Well the point is not what an x86 or ARM based CPU can or cannot do. The point is how can they filter network traffic, without the use of kernel? Even meltdown and spectre can't do it without a process(part of a kernel) involved.

                  1. @SamsonovAnton 4y

                    No, you got it all wrong. CPUs won't process the traffic as intended instead of firewall software — but they may react to the very same traffic in their very own way, thus creating a backdoor.

                    1. dev_meme 4y

                      Nope a CPU won't do that unless you have some external chip involved to feed that data to it and take back the results or some chip which has some compiler burnt as firmware.

                    2. dev_meme 4y

                      A CPU, in very pure terms is like a function, which you feed data to and receive the results. Now, if you wanna call an SoC a CPU, it's totally absurd.

                      1. @SamsonovAnton 4y

                        Let's go step by step: Regular software may access the NIC ports. CPU / SB firmware may access the NIC ports — at least integrated ones, but also any other Intel-based controllers on PCI bus. What prevents the CPU / SB firmware to react to ingress network traffic or even inject self-crafted packets (frames) into the egress queue?

                        1. dev_meme 4y

                          No software can do anything without it being on a persistent storage(disk, NAS, firmware) and then memory to finally feed off the CPU.

                          1. @SamsonovAnton 4y

                            This "software" is called firmware and resides in a persistent memory inside the CPU, but also is loaded by BIOS and/or OS from an totally opaque file supplied by the CPU vendor.

                            1. dev_meme 4y

                              I already wrote firmware in parentheses

                      2. @oficsu 4y

                        Functions sometimes have a shared mutable state, bugs and vulnerabilities A hacked cpu might disable the firewall (because it has enough cache memory to detect patterns of known software or its parts, including an OS, and it can freely access and inspect all memory regions) and forward malformed packets to the other firewalls At the end of this chain, all firewalls will be compromised

                        1. dev_meme 4y

                          Again, you didn't get the point and started to send random things. I didn't say a function can't be buggy. We write smart contracts carefully for precisely this reason. The point is a CPU alone cannot do it. Cache is empty when it's not being fed off by the RAM. RAM is empty when it's not being fed off by a persistent storage(disk, NAS, firmware). So cache can't store any pattern which later it can use as an exploit. No malware can do anything unless it has a process to work with. Even meltdown and spectre can't. So that's the point. There is nothing like a hacked CPU! There are exploits, rootkits, backdoors, etc. all of which work at OS, kernel and process(in general) level(at best, they can affect the fw). You can't program a CPU via a software to make it malicious for an OS.

                          1. @oficsu 4y

                            Are we talking about impossibility or how hard it is? Your arguments are right in the second case, but not in the first tl;dr: you should prove that a cpu itself isn't already a SoC, and you can't because you can't trust the vendor in the context of backdoors >> you can't program a CPU via a software to make it malicious for an OS As a user, you can't. As the vendor, you can. The talk is about backdoors, about the second >> RAM is empty when it's not being fed No, it's not. In the context of this talk, we have at least firewall code and a network packet in the RAM and the cpu cache, so they aren't empty And you can't prove, the cpu doesn't already have a built-in malicious payload At some point, a network packet ends up in the cpu cache. And you can't prove there is no any algorithm inside that can disable firewall based on both a packet and software patterns If you're going to prove it's impossible at all (impossible, not too hard), you need to follow the formal logic and prove both: * a cpu doesn't know the patterns of executing software (os or firewall) * software doesn't allow a network packet to go through cpu cache in an unchanged or a known state (e.g. other hardware can compress or encrypt packets) And to prove both of this in general, you need to prove these for each potential combination of cpu, os and firewall. To prove this in the context of a particular combination, you need to reverse that cpu (and it's nearly impossible too) >> Even meltdown and spectre Because it's another type of vulnerability

                            1. dev_meme 4y

                              you should prove that a cpu itself isn't already a SoC, and you can't because you can't trust the vendor in the context of backdoors A CPU(processor, the term used by a person, due to which the discussion originally started) is a combination of transistors put together and then fabricated. Modern ways of creating processors have tried to incorrectly stretch this definition to include NB(as AMD merged it some years ago and the rest followed suit), SB, other peripheral connects, unified memory and so on. But, the original definition of a CPU hasn't changed, it is a group of transistors put together in a certain way as to complete calculations on 0s and 1s and return the results. A CPU takes this data from a combination of registers, caches, memory and finally persistent storage and reverts back the processed data in the form of 0s and 1s in the same order as it received the unprocessed data. This is in part, analogous to the ROM misconception that many, including but not limited to, the mobile vendors have spread to stretch it to PROM, EPROM, EEPROM and so on to the point where a mobile disk is incorrectly referred to as ROM. This does not however, change the initial and pure definition of a ROM. In a similar way, it doesn't change the pure and original definition of a CPU which is plugged inside the motherboard. A CPU DOES NOT include SB or other parts of an SoC, that would be called a system, not a processor, at least until you are sticking to the currently accepted standards. All those exploits, backdoors and so on form a part of some persistent storage, without which the CPU can't be exploited or create a malicious version of itself. It can just receive malicious code and act on it, giving the results as a consequence. Now this result is the thing that can harm a system, and by system, I mean OS, kernel, disk etc. No exploit can change a CPU to behave in a different way than it was designed to at the 0s and 1s level. As the vendor, you can. The talk is about backdoors, about the second Again, I'm not talking about some persistent chips(fw or something else) which is included with the CPU but the processor only. No, it's not. In the context of this talk, we have at least firewall code and a network packet in the RAM and the cpu cache, so they aren't empty The point here is, a CPU cannot by purely itself have some malicious code that works at the 0s and 1s level. That code must have been provided to it in the form of a high-level or at the very least binary language, it cannot create malicious binary code on its own. And that malicious code would have to have been provided at the level of the persistent storage, not at the level of RAM, because you can't load ELF binaries directly to the RAM, they have to go through a lot of stages, like ELF linking. Even if you go through that stage(which almost no one would), maybe you feed it through /dev/stdout or things like UPX, you can't at any cost modify the registers or caches, which are actually a part of the CPU, to serve exploits on reboots and power offs, i.e. you can't modify them to behave differently than they were intended to, using an exploit. They will reset after a reboot. You maybe able to(and believe me it's not trivial) read the cache contents, if you sniff on the content addressable cache's system bus, but again, at that point, you aren't injecting any malicious code pragmatically, even from a persistent source. So, the point of a processor doing it on its own is totally absurd. And you can't prove, the cpu doesn't already have a built-in malicious payload I totally proved it for a pure processor, not a whole system, only who's name is a processor. At some point, a network packet ends up in the cpu cache. And you can't prove there is no any algorithm inside that can disable firewall based on both a packet and software patterns It will have to be originated by a persistent storage, and again it can't modify CPU cache to remain there always, a cache is empty on each reboot.

                            2. dev_meme 4y

                              And to prove both of this in general, you need to prove these for each potential combination of cpu, os and firewall. To prove this in the context of a particular combination, you need to reverse that cpu (and it's nearly impossible too) This thing is trivial so, I would assume it's not needed to prove it, however, it surely can be proved with formal logic: it is impossible to prove the reverse of it, i.e. a software modified the contents of a CPU, and after that the CPU started to serve exploits and malicious code on its own. Because it's another type of vulnerability The point here was, even these CPU attacks needed a process(on a persistent storage) to cause an exploit on a CPU.

                              1. @oficsu 4y

                                >> Again, I'm not talking about some persistent chips(fw or something else) which is included with the CPU but the processor only. And... why? Because we're talking about this cpu. Just a little black box sold by intel/amd (for example). It can contain any software or hardware malicious payload inside the box. Can't it?

                                1. @RiedleroD 4y

                                  it can't because intel and amd have to abide by the law /s

                                  1. Deleted Account 4y

                                    What about Intell Me ? Poor documented feature ? ))

                                2. dev_meme 4y

                                  It may or may contain any chip inside of it. However, I'm not talking about only these but a CPU in general. A processor which has the components which are accepted as the standard now. Now, if a company implements a hidden chip or not, if a software company tracks your activity or not, sells your cookies or not is totally indeterministic and not the norm. You can make assumptions based on the standard, not imagining an exception that may be out there somewhere.

                                  1. @oficsu 4y

                                    Software practice shows us that the standard is to track users. Do you think that hardware design was built upon other standards? Why? InfoSec isn't about baseless trust. It's about strong guarantees. And we don't have such guarantees

                                    1. dev_meme 4y

                                      The point of tracking isn't a standard, but appears to be as cookie selling is a thing, but wasn't designed keeping that in mind. It's not even the point, this thing was said in support of the hidden chip fact. You're going on a totally distracted path.

          2. @SamsonovAnton 4y

            The meme was about backdoors. Those can be of any kind. Imagine a "Wake-on-LAN" kind of specially crafted packet, that acts as "Ping of Death", or makes the packet payload to executed in privileged mode, totally transparent to the main OS and its "Trusted Platform" means.

            1. @L2CacheGay 4y

              And where do you suggest that payload would even run?

              1. @L2CacheGay 4y

                From the perspective of the hardware reacting to such a package you wouldn’t have much control over the CPU package itself or what goes on inside it

                1. @SamsonovAnton 4y

                  Do you know what a System Management Mode of x86 CPUs is? It's there since 386. And now we also have Intel Management Engine running in even higher privileged mode. https://en.wikipedia.org/wiki/System_Management_Mode https://en.wikipedia.org/wiki/Intel_Management_Engine

                  1. @L2CacheGay 4y

                    Of course

          3. @feedable 4y

            what is below kernel, anyway

            1. @feedable 4y

              can it go into userspace? yes it can, and it routinely does. can it go through ime? yes, it can too.

              1. dev_meme 4y

                Userspace is above the kernel in that regard.

                1. @feedable 4y

                  what exactly is below, then

                  1. dev_meme 4y

                    Firmware, Bootloader, SB etc.

                    1. @feedable 4y

                      bootloader will not continue to operate after the kernel is loaded. from the perspective of a booted system it's as if there were no bootloader in the first place

                      1. dev_meme 4y

                        Yes that's exactly what I'm saying as well

                      2. @feedable 4y

                        kernel does not need kernel to operate

                        1. dev_meme 4y

                          Kernel is very complex software, it has parts that need each other to complement them

                      3. dev_meme 4y

                        It's below the kernel

                        1. @feedable 4y

                          it won't execute after the kernel is loaded

                          1. @feedable 4y

                            it does not matter wether it is above or below

                            1. dev_meme 4y

                              Are you high

                              1. @feedable 4y

                                what

                            2. dev_meme 4y

                              Whether what is above or below?

                              1. @feedable 4y

                                not whenever, wether

                                1. @feedable 4y

                                  look up that word

                              2. dev_meme 4y

                                ?

                              3. @feedable 4y

                                the bootloader

                                1. @feedable 4y

                                  oh come on

                          2. dev_meme 4y

                            Yeah I know that

                          3. dev_meme 4y

                            It loads at boot time after POST

            2. @el_khatto 4y

              hardware

            3. dev_meme 4y

              Depends how you're talking. In general, firmware has data that doesn't need a kernel.

  3. @SamsonovAnton 4y

    Excavator FW.

  4. dev_meme 4y

    Wake on LAN works only when the system is in hibernate state and not when it's powered off, again the kernel is on at that time and the network traffic is going through the path of OS -> Kernel -> CPU. Is CPU doing any processing on the network traffic's 0s and 1s without the kernel being involved?

    1. @SamsonovAnton 4y

      The CPU (or southbridge, if any) may process network packets in parallel to the main OS, at least on integrated LAN ports.

    2. dev_meme 4y

      Have to disagree on "when the system is in hibernate state and not when it's powered off” Intel’s (at least) support WoL when machine is powered off (not with swtich ofc), thanks to same approach how , for example, old phones been able to work even when not connected to the socket (PoE)

      1. dev_meme 4y

        You can't do it from S5 stage, is what I meant

        1. dev_meme 4y

          https://www.intel.com/content/www/us/en/support/articles/000038313/ethernet-products.html

          1. dev_meme 4y

            can you do it from a totally powered off state?

            1. dev_meme 4y

              Like no power cord being inserted? On a desktop PC? Surely not

              1. dev_meme 4y

                [In reply to dev_meme] nope, totally powered off with all power cables inserted?

                1. dev_meme 4y

                  Yeah!

                  1. dev_meme 4y

                    have you ever tried it or saying it from online blogs?

                    1. dev_meme 4y

                      Well, let’s separate online blog and official Intel documnetation/website

                      1. dev_meme 4y

                        Well, if you find any recent one for Linux systems, send me over, it would be great help for me saving power.

                        1. dev_meme 4y

                          Could you clarify model of your network board/CPU/motherboard? 😄 And have you tried etherwake (with all required patches) And which distro you use, too

                          1. dev_meme 4y

                            Ubuntu and Centos only Z-490, Z-690 and X-570 Yes, ethewake didn't work in case it was totally off

                            1. dev_meme 4y

                              And at the same times it does function already while below S5, right?

                              1. dev_meme 4y

                                Yes it does, that's correct

                            2. dev_meme 4y

                              https://www.reddit.com/r/gigabyte/comments/gnujnz/x570_aorus_master_wakeonlan_usb_power_after/

                              1. dev_meme 4y

                                Anyway, just try to go through this discussion Definetly carefull research for each set of equipment is required

                                1. dev_meme 4y

                                  Anyway if you find, send over, thank you for all your help.

                                2. dev_meme 4y

                                  I sure will look into everything again, tried it all 2-3 years ago and there wasn't any such thing for Linux back then on my systems.

                              2. dev_meme 4y

                                Is this for Linux systems? And my mobo is X570 E-Gaming from Asus

                                1. dev_meme 4y

                                  Once again for Windows https://rog.asus.com/forum/showthread.php?101283-Wake-on-LAN-not-working-from-shutdown-Asus-Deluxe-Z170

                                  1. dev_meme 4y

                                    This is same thing over-over

                                  2. dev_meme 4y

                                    Just confirms that it MAY and somehow SHOULD work

                                    1. dev_meme 4y

                                      True

                                    2. dev_meme 4y

                                      And question of how to make it work in reality is a quest, not a question 😄

                                      1. dev_meme 4y

                                        I've suffered so I could say

      2. dev_meme 4y

        and POE is totally different to WOL, for WOL, you need some power, however low it maybe, you can't turn it on from powered off state, to be precise.

      3. dev_meme 4y

        If you do, you're correct in this regard.

    3. dev_meme 4y

      And I made this comment based totally on my experience

      1. dev_meme 4y

        I remember that it should work because many years ago, when this feature and some early version of VT-d been delivered with CPUs I read one in depth research article where one security researcher found that Intel firmware in his case was replaced with some weird one, instead of one provided on Intel’s website, while even checksums been same

        1. dev_meme 4y

          For those who got interested, sorry, I will not be able to find it. And it was written in Russian, somewhere between 2009 and 2012 But md5 at those days still been heavily used (unfortunatelly) and possibility to create collisions for not same data wasn’t… Well-known

          1. dev_meme 4y

            And #education repo about collision, for our fellow readers 😄 https://github.com/corkami/collisions#fastcoll-md5

          2. dev_meme 4y

            I've been using Linux since 2005 and haven't been known of such a thing

            1. dev_meme 4y

              What do you mean Linux/Windows?

        2. dev_meme 4y

          Well it must have been for Windows

  5. dev_meme 4y

    South bridge is not a part of the CPU

    1. @SamsonovAnton 4y

      It does not matter, as long as CPU/NB and SB (chip set, that us) form a solid hardware platform, tightly integrated with each other and controlled by an opaque, encrypted and signed firmware.

      1. dev_meme 4y

        My dear, a solid tightly coupled platform isn't called a processor, it's an SoC or a system.

  6. dev_meme 4y

    It's a part of the mobo

  7. dev_meme 4y

    Unlike the north bridge which was merged into the CPU some years ago by AMD and all else followed

  8. dev_meme 4y

    Stolen

  9. dev_meme 4y

    First of all SB is not a part of the CPU

    1. @SamsonovAnton 4y

      What's the deal with how many chips a processor is split into? It's just a matter of "IP blocks", lithography and packaging.

      1. dev_meme 4y

        A CPU(processor is not that), offcourse a CPU with one or more chips can do anything you burn inside the firmware or feed it via a persistent storage via the memory.

  10. dev_meme 4y

    Let's get that off

  11. dev_meme 4y

    Thanks

  12. @varn0 4y

    Best meme discussion so far, thanks folks 😂

  13. dev_meme 4y

    CPUs: 10900K, 12900K, 5950X

  14. dev_meme 4y

    I mean WOL

    1. dev_meme 4y

      Gotcha, yeah 🙁

  15. dev_meme 4y

    Thanks for your help

    1. dev_meme 4y

      Sorry for not finding anything really useful In corporate world for this purpose people buy sample hardware and test it to satisfy special requirements, like working WoL in specific PS

      1. dev_meme 4y

        And in case of NIX OSs Intel probably cares only about those big customers, for whom they may have all data and compatibility tables with links to drivers

      2. dev_meme 4y

        Hey not a problem buddy, you're not here from Intel, are you?

        1. dev_meme 4y

          Nope 😄 I’m @linegel

  16. dev_meme 4y

    Yeah, we similar one some time ago too 🙂

  17. dev_meme 4y

    Kernel is Ring 0. Then you have, Drivers: Ring 1, Hypervisors: Ring 2, Browsers: Ring 3

    1. @feedable 4y

      hypervisors are below kernels, aren't they?

      1. dev_meme 4y

        Nope

  18. dev_meme 4y

    Things that don't need kernel to operate

  19. dev_meme 4y

    Tell me which one?

  20. dev_meme 4y

    Not even baremetals

  21. dev_meme 4y

    Yes we weren't talking about bootloader here, it came into discussion as you asked what is loaded before a kernel is loaded

  22. dev_meme 4y

    Because bootloaders can inject boot sector viruses, we were talking purely a CPU

    1. @feedable 4y

      what are you trying to prove anyway

  23. dev_meme 4y

    Nothing, I was trying to tell that a CPU alone can't be malicious

  24. dev_meme 4y

    It's like a pure function that takes input processes it and returns it.

    1. @feedable 4y

      take ime for example

      1. @feedable 4y

        is it a part of a cpu?

        1. @feedable 4y

          can it be malicious?

      2. dev_meme 4y

        What's an IME

        1. @feedable 4y

          https://en.wikipedia.org/wiki/Intel_Management_Engine

  25. dev_meme 4y

    It doesn't have a persistent storage by itself, so it the software(firewall, exploit) isn't being fed off by the persistent storage, it won't do anything

    1. @feedable 4y

      yes, but without that exact storage it won't be able to do anything, harmful or not

      1. dev_meme 4y

        Well that's exactly what I said

  26. dev_meme 4y

    It's a part of the mobo(like SB), not a CPU

    1. @feedable 4y

      it exists on the crystal

      1. @feedable 4y

        i mean, if you are arbitrarily going to chop off parts of the cpu until it fits your criteria this discussion would not make any sense

        1. dev_meme 4y

          neither will it make sense if you try to include the parts of a motherboard into a CPU(processor)

Use J and K for navigation