XL Foods Crashes and Burns

XL Foods is a huge beef processor in Alberta, Canada. They distribute to much of Canada and USA. Last August, they produced shipments that began to be identified as contaminated with a particularly virulent form of e. coli bacteria. Because meat is not sampled 100%, government agencies took some time to determine the scope of the problem. A large number of recalls of product were made but eventually the licence of the business was revoked.

“Establishment 38 had monitoring measures in place but was not properly conducting trend analysis of the data it collected. The CFIA review found that the plant needs to improve its trend analysis and also stengthen its response measures when a higher than normal number of detections are made.

In addition, the company’s control measures for meat that tested positive for E. coli O157:H7 were not always being followed correctly. While containers of meat testing positive for E. coli O157:H7 were properly handled, a small number of containers produced immediately before and after the contaminated product were not always diverted from the fresh meat line. This process, known as bracketing, is an established food safety control.”

see Questions and Answers Recall of Specific Products from XL Foods Inc. – Establishment 38, Brooks, Alberta – Food – Canadian Food Inspection Agency.

We see this kind of failure of technology often. The more complex a system the more hidden are the details. XL apparently did not study their own test results well enough to trigger their internal alarms. If they had widespread recalls and the loss of the licence might have been prevented. What were they thinking? Trying to save a dollar? Was the wrong person put in charge of quality-control? We may never know but once again, a number of factors that should have prevented the problem all failed at the same time.

In technology, the only way to protect complex systems is to have a layer of defences and each one has to be tuned up and maintained or the whole thing can fail as XL did. Governments were complicit, too for they have not sampled often enough. If all exports to USA had not been sampled, this thing might have become much bigger and more tragic. Even so, some of the product entered USA. More than one layer had to work but they all failed. Not all samples of contaminated meat test positive but it only takes one bacterium to make a real mess.

Thorough cooking is the last line of defence. Make sure to cook that hamburger through. I actually know people who like their hamburger “rare”, like steaks, yet hamburger is nearly an ideal product in which the bacteria grow. I never eat undercooked meat.

For me, the operating system is the last line of defence in IT. If it was designed to be single-user, designed by salesmen, and forced on people in an uncompetitive market, the results will be disastrous. That’s why I recommend Debian GNU/Linux, an OS that works for you and not against you like the products of Wintel.

About Robert Pogson

I am a retired teacher in Canada. I taught in the subject areas where I have worked for almost forty years: maths, physics, chemistry and computers. I love hunting, fishing, picking berries and mushrooms, too.
This entry was posted in technology. Bookmark the permalink.

39 Responses to XL Foods Crashes and Burns

  1. oiaohm says:

    That Exploit Guy
    –No, the ring model by design allows inner rings to access memory segments belonging to outer rings. Maybe you should consult this thing called a “textbook”?–
    That is the x86 model of rings. This is the problem.

    Other archs took other paths. PAE also allows that not to be always the case.

    SPARC you need to look at the MPU the differences in design that give the SMEP and SMAP style protection is a little long for a blog post.

  2. That Exploit Guy says:

    @oiaohm

    ‘SMEP bit make execute obey ring settings.’

    No, the ring model by design allows inner rings to access memory segments belonging to outer rings. Maybe you should consult this thing called a “textbook”?

    Finding blocks RWX in ring 0 on SMAP intel systems get you no where attempting to write to it from ring 3. ‘

    Hmph… Did you read this, fail to comprehend it and decide instead to make up this bit of nonsense just to pretend you know something? This (garbled) sentence certainly points to this likely possibility.

    Anyway, Set-AC and Clear-AC are instructions for manipulating the AC (alignment check) bit in the EFLAGS register, which is used to determine if SMAP is to be enforced or not in the yet-to-be-released Haswell processors (and for checking unaligned memory access in 486 and up). CLAC unsets the AC bit, which results the CPU not raising a page fault when kernel mode code attempts to access memory belonging to the user space. The entire mechanism has simply nothing to do with memory belonging to the kernel space and is thus incapable of dealing with the scenario described in the “RWX kernel page” section.

    ‘These features have existed in sparc chips over over 15 years the tech was new for Intel basically old common crud for everyone else including arm.’

    Interesting. As far as I am aware, SPARC does alignment check but not anything even remotely similar to SMEP or SMAP. Maybe you would like to substantiate that a bit?

  3. oiaohm says:

    That Exploit Guy there is two features.

    Linux 3.7 has this to go in.
    SMEP and SMAP. All the flaws the guy lists for getting around SMEP. Are basically killed by SMAP.

    SMEP bit make execute obey ring settings.

    SMAP that prevents writing where you should not based on ring. Yes one letter difference between the two things. Finding blocks RWX in ring 0 on SMAP intel systems get you no where attempting to write to it from ring 3. You need to be ring 0 to write to them. Lot of common attacks against SMEP+NX is worthless against SMAP+SMEP+NX. Copy from user-space function will have to be used unless you go by the module loader. Big bad news under Linux copy from user-space function auto applies NX.

    To change ring level access of a page you need the instructions CLAC/STAC only in ring 0.

    The is the progressive problem. Each time attacks find a weakness the hardware is now altering to prevent.

    And the big reason why the security lady would have got in no trouble. These features have existed in sparc chips over over 15 years the tech was new for Intel basically old common crud for everyone else including arm. x86 is late to the security party. Attackers have got use to taking on defective hardware.

    That Exploit Guy attackers have had 15+ years to beat this style of protection. Fully implemented we know the results. Attack styles against kernel will be limited to return to object attacks. Tech to prevent those already exists. One problem x86 chips don’t have that yet.

  4. That Exploit Guy says:

    @oiaohm

    ‘Funny enough intel video cards recent generations have a hardware video memory manager.’

    Let me guess, you looked up something like this and decided it’s somehow related to security. Well, it isn’t.

    ‘You put your security information into that and a sideways attack is not possible using gpu code if the permissions have been assigned.’

    Look – you invented this thing called a “sideways” attack (which I mistook for a real form of attacks known as a “side-channel” attack, which takes form in such sophisticated methods as looking over someone’s shoulders for the password and putting a fake card reader on an ATM), and then somehow the only way to defeat this obscure mechanism is to either use SELinux or employ hardware acceleration features that have naught to do with operating systems security. What you give me here is not a real argument – it’s science fiction, and, in all honesty, it’s hardly an interesting read, either.

    ‘Really get a copy of Windows 8 and check how it does things. Windows using the keys in the UEFI KEK for things other than booting. Yes there are more than 1 certificate store.’

    Apparently, you seem to have difficulty grasping the basics of digital signatures. You probably looked at Windows 8 certificate store and decided it somehow has control over the signatures database or the key enrollment key database. Well, guess what – because UEFI isn’t designed by oiaohm, it doesn’t:

    “The OEM stores the signature database, revoked signatures database, and KEK signature databases on the firmware nonvolatile RAM (NV-RAM) at manufacturing time. These signature databases must be included to boot Windows by using Secure Boot.”

    In other words, you can’t alter the KEK database without overwriting the NVRAM containing the UEFI firmware, and features for locking firmware from unauthorised updates have been around for about as long as NVRAM has been used for storing mainboard BIOS.

    ‘Joanna Rutkowska only talks about intel chips. She does not have AMD. That is important. The feature has existed on AMD chips for years.’

    Sure, sure! Because a renowned security expert would certainly have not got lambasted by her peers for proposing an existing thing as a new idea at a technical conference, now would she?

    ‘NX did not block ring to ring attacks. Also Linux was not setting NX on loaded modules.’

    That’s because it was never the purpose of NX to prevent kernel mode code from arbitrarily executing code belonging to user mode applications.

    ‘SMEP fairly much shuts the door of being attacked.’

    No, it won’t. Just as NX was unable to stop most buffer overflow exploits, SMEP will be demostrably defeated in one way or another on different operating systems in a short amount of time. Heck, there are people already working on how to defeat it on Linux.

    ‘NX did see a class of attacks just die.’

    No, it merely made shellcode injection more difficult, but it certainly didn’t make any “class” of attacks disappear or decrease in use.

    ‘That Exploit Guy Selinux has a feature called system-call auditing.’

    Which works by looking at policies and credentials, which almost every exploit in circulation is designed to defeat first and foremost. Again, you are basing your argument on fantasy, not reality.

    ‘Seccomp filters on the other hand does include the possibility of heuristics.’

    No, a seccomp filter does pretty much the same thing as SELinux in regards to syscalls with the only difference that it doesn’t give you the facility to define elaborate access policies.

    On top of that, you are still mistaking tools for establishing bureaucratic secrecy as measures against malicious attacks. No, SELinux is not anti-virus software. It never was, and it never will be.

    ‘Those credentials are per application not per user. So user running as admin on a harded Selinux gets you program and runs it and it does something more than what a normal user should it killed. You application did not have the required credentials.’

    And what difference is that supposed to make? A malicious attack is usually aimed at defeating credentials. All that a policy of establishing credentials does is squat to the attacker. Even Linux without SELinux enforces an access policy of its own (i.e. root/non-root). So what?

    What Red Hat does is essentially trying to promote a use of something that it is not designed for, and you, having read their product brouchers, decide that you now suddenly have the knowledge of a security expert. No, you don’t, so stop fooling yourself.

  5. oiaohm says:

    That Exploit Guy SMEP in the current patch that has gone in. If your driver in Linux is not compatible on hardware that is SMEP your driver will die. Don’t worry about security flaw flat kernel panic.

    This is way different to when NX was implemented in the Linux kernel were you could go hey we will not bother implementing this. Same effect exists on AMD and VIA hardware. So most drivers in Linux do the pass from userspace to kernel space and back one particular way. The odds are any SMEP issues with drivers is almost zero. Because the feature has been implemented by AMD and VIA for ages. Windows does not support the AMD or VIA or the Intel implementation. Most likely be windows 9 before you see SMEP.

  6. oiaohm says:

    That Exploit Guy
    –A “memory manager” is a portion of the video card driver that governs the use of video memory, i.e. it enforces segmentation. In other words, it’s a software thing.–
    That is the security flaw. In CPU memory management of video memory does not contain programs running in the GPU.

    Funny enough intel video cards recent generations have a hardware video memory manager. You put your security information into that and a sideways attack is not possible using gpu code if the permissions have been assigned. You gpu code has a memory map of what memory in the gpu is allowed to access. Missing hardware feature equals security hole.

    –UEFI doesn’t share the same certificate store as that of the operating system itself. Check your facts.– Really get a copy of Windows 8 and check how it does things. Windows using the keys in the UEFI KEK for things other than booting. Yes there are more than 1 certificate store.

    Joanna Rutkowska only talks about intel chips. She does not have AMD. That is important. The feature has existed on AMD chips for years.

    Because the SMEP ability is not new AMD chips.
    “There will always be ways to defeat such mechanisms, as in the case of SMEP and NX.”
    NX did not block ring to ring attacks. Also Linux was not setting NX on loaded modules.

    SMEP fairly much shuts the door of being attacked.

    NX did see a class of attacks just die. Most of the weakness around NX were areas where it had not been enabled. SMEP on Linux is a different matter its coming out the box enabled everywhere it needs to be.

    In fact NX bit before the loader was fixed saw more most attacks against the Linux kernel move to the loaded drivers where NX was not enabled. Because many attacks just would not work.

    The true fact of the matter this is no such thing as defeat theses hardware changes and keep on doing the same classes of attacks.

    So ring 3 to ring 0 using attacks using executable code are basically dead in the future. So getting into ring 0 and running what ever code you want will be data struct based privilege exploits or tricking user.

    The problem is SMEP and NX come into one piece. Linux markers everything bar kernel module at runtime coming from user-space as NX. Executable code inserts into the Linux kernel have been depending on the fact that usermode executable bit and kernel mode executable bit are the same.

    AMD processes the NX bit is different between rings automatically under Linux. If memory was created in a different ring its automatically NX to other rings. AMD implemented the NX bit slightly differently. Result the chip is not exploitable the same way.

    That Exploit Guy Selinux has a feature called system-call auditing. That dumps every arguement of a syscall. Selinux also has the means to check ever argument. Of course you don’t most of the time because its a performance over head. You are reading redhat documentation not implement is self. Redhat talks about how SeLinux generally operates and then they go in production and use it a slightly different way.

    That Exploit Guy
    –It can check for “certain” arguments, and I am quoting from one of those Red Hat brouchers that you treat as if they were the word of God.–
    I don’t treat those at the word of God. Because they do in fact lead you away from what Redhat really does.
    –It doesn’t not discern by heuristics, but credentials.–
    This is correct neither does first generation anti-virus. Seccomp filters on the other hand does include the possibility of heuristics.

    Linux is progressively hardening.

    That Exploit Guy a lot of what I am talking about in Linux like cgroups has been off by default. Its only recently changed to on by default in a lot of distributions.

    Lot of the attack vectors are disappearing. The attacks are mostly being achieved because the security is turned off.

    That Exploit Guy history when it comes security does not mean it will keep on repeating. Lot of attack methods are about to end forever.

    That Exploit Guy a stock Linux kernel is no where near as predictable as you make out.

    –As long as you have the right credentials, everything you do is legal to SELinux.–
    Those credentials are per application not per user. So user running as admin on a harded Selinux gets you program and runs it and it does something more than what a normal user should it killed. You application did not have the required credentials.

    Security permissions need to be per Application and per user not just per user. Cgroups using systemd in userspace are align up for per application permissions on everything. So the Linux DAC will have applications and user permissions that the mandroary access controls on Linux have provided for years.

    This is a design flaw that makes attacking windows simpler.

  7. TEG’s comment was held for moderation for having excessive adjectives…(joke)

  8. That Exploit Guy says:

    Nice. My comment gets eaten by the spam filter again.

    @oiaohm

    ‘That Exploit Guy reality is a scary one. AMD processors for the past 6 years have had a better memory manager for preventing security bugs.’

    Now it seems clear to me you don’t even understand what I mean by “memory manager”.

    A “memory manager” is a portion of the video card driver that governs the use of video memory, i.e. it enforces segmentation. In other words, it’s a software thing.

    As I said, maybe you would like to read up on the subject before careening off into such irrelevant (and factually deficient) tangents?

  9. That Exploit Guy says:

    @oiaohm

    ‘The that is only one part of UEFI secure boot framework. Second is a store of keys.’

    UEFI doesn’t share the same certificate store as that of the operating system itself. Check your facts.

    ‘The kernel faults you are worried about will die out for Linux over the next few hardware generations.’

    Glad that you cited the grsec forums. Did Brad Spengler tell anything you about “Chadder Bay”?

    ‘The kernel faults you are worried about will die out for Linux over the next few hardware generations.’

    No, SMAP will merely make exploiting vulnerability more complex. There will always be ways to defeat such mechanisms, as in the case of SMEP and NX. Also, why not ask Joanna Rutkowska what she thinks about that (provided that she doesn’t mind reading barely comprehensible gibberish)?

    ‘Bugger for Windows users. Same problem its windows again as why windows don’t have PAE supporting 64G of ram on a 32 bit system because Microsoft was unable to get third parties to update drivers.’

    That’s interesting. On one hand, you think targeting stock kernels require time-travelling ability. On the other hand, you think targeting device drivers not compiled with the additional features are easy to encounter.

    There is simply no end to your wild imaginations, is it?

    ‘With hardware assistance that is coming getting into kernel space is even harder.’

    I would rather see you copying and pasting someone else’s blog entry and pretend it’s yours than read through a moonspeak version of it translated by you.

    You see what I am getting at here?

    ‘In fact to idiot who don’t understand the LSM framework don’t notice that it is possible for the LSM if it wishes to notice. Because it can check the arguments of syscalls not just the name of the syscall used.’

    It can check for “certain” arguments, and I am quoting from one of those Red Hat brouchers that you treat as if they were the word of God. Any argument not directly related to credentials are simply outside the scope of SELinux.

    Again, check your facts.

    ‘This is why Selinux is very much like an anti-virus.’

    Again, you have completely misunderstood the purpose of SELinux. SELinux follows policies, not patterns. It doesn’t not discern by heuristics, but credentials. As long as you have the right credentials, everything you do is legal to SELinux.

    Stop trying to promote something you don’t understand.

    ‘Do those directories have to be real. cgroups can fake both. Selinux accessing a device or a proc file/folder you should not be is termination.’

    Again, you are arguing against the possibility of something that has been achieved many times before. Why not go and do a bit of research before mindlessly throwing empty words at me?

    ‘That Exploit Guy there is a policy at play active use-able exploit code you do not hand around. Particularly when its cross platform.’

    Mind if I ask you whose policy it is and why you are bound by it?

    I think I have got a good grasp already as to what you are and aren’t, but I am nevertheless curious to see how deep a hole you are willing to dig yourself into.

    ‘Like if you capture screen and find out what anti-virus you are facing off against. Now you can use exploits the anti-virus don’t know.’

    Hang on – what exactly is your scenario again? Or am I suppose to fill in the blanks here somewhat?

  10. oiaohm says:

    That Exploit Guy reality is a scary one. AMD processors for the past 6 years have had a better memory manager for preventing security bugs.

    There are a lot of issues in the memory managers include the ones connected to the GPU’s.

    Its one thing to go after bug free code. Its another to be sitting on top of hardware where the bugs simple cannot work. To get code into kernel space as executable will require 1 of the following.

    1) Load a driver. Linux systems support secure boot these will have to be signed.
    2) Kexec. Linux systems supporting secure boot this this will also have to be signed.
    3) find weakness in one of the memory managers to get to where you should not.

    Hardware is not going to allow any other option. There have been many kernel attacks against Linux that in x86 hardware only work on Intel chips don’t work on Amd x86 chips. Yes this is another thing that brings attackers undone attacking Linux. Its a x86-64 bit machine there is a point I can send to userspace to run some executable code in kernel space if that machine happens to be an AMD for the past 5 years that fails.

    Reality is the Linux is not as easy to attack because the security features of the different CPU chips have been implemented.

    –You are targeting a fixed set of vulnerabilities on popular architectures (e.g. x86, x86_64), so what exactly is the difficulty in finding out if they exist on a machine that runs a stock kernel from the repository?–

    Popular architectures are far more segmented on Linux. x86_64 kernel image runs differently on a intel chip or via or amd. This goes down to security handling.

    CVE and others don’t documented if security flaws are Intel, AMD or VIA only on Linux. Or even if they are only particular generations of CPU’s.

    That Exploit Guy Windows is way too easy.

  11. oiaohm says:

    That Exploit Guy Microsoft is also use UEFI secure boot for key storage for drivers and update manager.

    –The one and only purpose of Secure Boot is to prevent kernels without proper signatures from loading into memory. Maybe you would like to look up on the subject matter before commenting on it?–

    The that is only one part of UEFI secure boot framework. Second is a store of keys. Microsoft is using this feature. Not only is the keys to OS kernel in the secure boot but the keys to drivers are in there as well. There is also keys for updates also inside the store as well. Basically I have already looked at Windows 8 secureboot implementation That Exploit Guy. Not just the description of recommended usage of UEFI. This is why windows 8 cannot work on a system with UEFI bios because then it would not have its keys for its update system.

    The reality I don’t need to worry that much about kernel space with Linux in the short term future tech.

    That Exploit Guy hardware I mentioned it once that the hardware of current cpus is weak did you not understand what I was talking about. The kernel faults you are worried about will die out for Linux over the next few hardware generations.
    http://forums.grsecurity.net/viewtopic.php?f=7&t=3046

    That Exploit Guy hardware kills most of the attacks against kernel space dead. Wait to implement this you need to update your driver code. Bugger for Windows users. Same problem its windows again as why windows don’t have PAE supporting 64G of ram on a 32 bit system because Microsoft was unable to get third parties to update drivers.

    With hardware assistance that is coming getting into kernel space is even harder. Since executable code in user-space will not be executable code in kernel space(yes one of the x86 design errors with NX bits).

    NX bit error is there was no difference between kernel space and user-space NX bit. Same with writeable memory and executable memory. The memory manager on the cpu has been too weak so lot of kernel exploits have been possible. We are at long last getting memory managers that have a clear understand of rings and virtualisation. Result is attacks where you allocate something in userspace and trick the kernel to enter it are not going to happen any more. All data memory in kernel space is no executable. The paths into the kernel will no long be simple syscall attacks. Instead attackers will have to do horible return to function attacks. This is particularly hard to pull of against kernel space.

    The fixes now mean the memory manager knows what is a kernel memory block what is a user memory block. So kernel cannot execute into a user memory block ever due to the fix coming. This has exist in other non x86 processors for a while. Linux supports these other processors by the way that have not had this bug.

    That Exploit Guy
    –Remember, when you use syscall, you are invoking a function provided by the kernel itself. If you think an LSM is in any way capable to notice that a bug in the function is being exploited in one way or another, then think again.–

    In fact to idiot who don’t understand the LSM framework don’t notice that it is possible for the LSM if it wishes to notice. Because it can check the arguments of syscalls not just the name of the syscall used. Selinux supports checking the arguements. But just like an anti-virus Selinux has to have a profile(signature) of the attack.

    The magic I call a flawed syscall I get the kernel is not true on Linux. You need other conditions for that to work. LSM like Selinux being disabled or not knowing you attack. Seccomp filter not being around the application or not knowing the attack. Either know the attack that the syscall flaw in kernel means nothing. Because you are not going to be able to get that far you are going to trip the security. This is why Selinux is very much like an anti-virus. This is also why it policy is horible. Have you ever looked at anti-virus signatures then look at Selinux policies and you notice some commonality.

    That Exploit Guy
    –Also, have you noticed that the Linux kernel by tradition exposes itself in some other ways than just C functions? Why not go to your /dev and /proc directories and have a look?–
    Do those directories have to be real. cgroups can fake both. Selinux accessing a device or a proc file/folder you should not be is termination.

    That Exploit Guy Linux changes over its kernel more often than Windows. This is why the window of attack is not as long. A kernel attack against a Linux system as a lot more limited time frame.

    –So you have no example of your own, and you are reluctant to cite a source from elsewhere. Isn’t that a prime example of hand-waving right there?–
    That Exploit Guy there is a policy at play active use-able exploit code you do not hand around. Particularly when its cross platform.

    –GPU accelerated VNC ought not to be a security issue at all.– Really to attack a system more information helps.

    Like if you capture screen and find out what anti-virus you are facing off against. Now you can use exploits the anti-virus don’t know. Please note my example using html5 that not the tech with the problem but there something else web based where you can pull off exactly what I described now. Exactly why can something running in a web page see the complete computer screen. Not a good outcome.

  12. That Exploit Guy says:

    @oiaohm

    ‘Because the attack I am looking at is attacking a companies network.’

    So now you are saying that you want to add your certificate to the pool. This does not seem to even remotely similar to what you have originally proposed. Getting cold feet, oiaohm?

    Anyway, even if this were what you had originally proposed (and it wasn’t), you would still need to package your driver for the update system with the right certificate, which is a completely different thing to the one you use for the driver itself. So the problem remains that it is a convoluted method of intrusion that heavily relies on conincidence, not calculations. This is not to mention that most of the actions will be recorded and viewable in the Event Viewer, which completely defeats your intention to avoid being detected. This is why the “established” way to inject your rootkit is to disable any auditing mechanism in your path first, SELinux or not.

    ‘This is why MS is trying to go secureboot and take these keys outside the OS. Since these keys are now outside the kernel your new target is not windows.’

    The one and only purpose of Secure Boot is to prevent kernels without proper signatures from loading into memory. Maybe you would like to look up on the subject matter before commenting on it?

    ‘That Exploit Guy I have an application running with Linux LSM granted permissions. How can application find out what those are. The answer is why SELinux and others cause applications hell at times. Is there is zero query function if application is allowed todo something.’

    *Sigh* Do you have any actual experience in working with POSIX syscalls? It seems pretty obvious to me now that the bulk of the responses from you are based on how you think things works rather how they actually work.

    ‘What do they have a Tardis or something that can time travel. The reality is the target is moving. So its not possible to test your rootkit to be sure that a kernel exploit will still be their or function how you expect.’

    I don’t think you need to be Dr. Who to know when an update is available from the kernel. You are targeting a fixed set of vulnerabilities on popular architectures (e.g. x86, x86_64), so what exactly is the difficulty in finding out if they exist on a machine that runs a stock kernel from the repository?

    Stop making excuses – people have done this before many times, so don’t tell me that it is somehow an unlikely feat.

    ‘That Exploit Guy most malware and viruses don’t primary hit the kernel on any OS. Its not required.’

    More wild guesstimates/hyperboles. What makes you think that most malware doesn’t target the kernel? After all, it is the key to completely hide your presense in the machine you have hijacked, and it’s ridiculous to think that anyone other than a complete amateur will leave your precious little LSM untouched.

    ‘That Exploit Guy getting the kernel is simpler under windows because you can try everything. Linux causes you to presume that a LSM might be there, Might be active so you restrict your attack even on systems not running a LSM.’

    Again, if you think Windows does not do any kind of auditing, you are sorely mistaken. Almost every piece of malware in the last 10 years that manages to achieve wide circulation in one way or another attempts to hide its activities by injecting code to the kernel space. This includes some variants of Mr. Pogson’s personal favourite conficker.

    ‘Taking precautions against the LSM is only use the functions the program you broken into uses. Like changing an ACL is your application LSM approved todo that. Maybe not since it does not do that. Now you list of workable attacks against each service drops massively.’

    Again, you are assuming that an attacker will use the syscalls in question trivially and normally in order to mount an attack. Remember, when you use syscall, you are invoking a function provided by the kernel itself. If you think an LSM is in any way capable to notice that a bug in the function is being exploited in one way or another, then think again.

    Also, have you noticed that the Linux kernel by tradition exposes itself in some other ways than just C functions? Why not go to your /dev and /proc directories and have a look?

    ‘Joanna Rutkowska does not cover the kvm one. That is a different developer. I did not say that using kvm or xen were my ideas.’

    I am pretty sure Xen was merely an implementation decision rather than the concept itself, but I am nevertheless impressed that you did not go and take credits for yourself this time around.

    ‘Its gpu instructions That Exploit Guy and I am not giving you the code of it. Because you should have found it. There are examples of GPU accelerated vnc and so on.’

    So you have no example of your own, and you are reluctant to cite a source from elsewhere. Isn’t that a prime example of hand-waving right there?

    Let’s assume that’s indeed the case, you know what makes it irrelevant for the most part?

    A memory manager.

    A key purpose of a memory manager is to enforce segmentations in the video buffer. Unless the memory manager itself is buggy (which has happened to the NVidia driver series but subsequently been fixed, but I digress), GPU accelerated VNC ought not to be a security issue at all.

    Note that I am not defending NVidia in anyway. I have never studied the driver in depth and most of the discussion on the Internet about it are sketchy at best. What I am saying here is that may be you should consider learning a bit more about the fundamental things about video buffer management before attempt making comments on it. That will make the discussion more meaningful and not completely one-side as it is (and you should be grateful I am continually feeding you with information despite you given nothing other than your subpar science fiction in return.)

  13. oiaohm says:

    Opps copied pasted that one by mistake.

  14. oiaohm says:

    That Exploit Guy I was talking about digital signatures to access other servers and data on the system. With high enough privilege you can add your own approved signatures under windows to the update system or change the ones that are there.

    –The reason you need the password for the original private key (which you don’t have anyway) is completely beyond me.–
    Because the attack I am looking at is attacking a companies network.
    http://msdn.microsoft.com/en-us/library/windows/hardware/ff552275%28v=vs.85%29.aspx

    If you read you will find that company can add there own keys for drivers and there own extensions. The Microsoft Private key is not the only one that you can sign with. That Exploit Guy yes it possible to generate my own. This is the point once you have enough privilege you can even replace the Microsoft signing key and where the machine gets updates from. So now enable you to protect your exploited machine from being undone by windows update. This does not require hitting the kernel. Hitting the kernel might get you there sooner. Same is true for most update systems. Once you are high enough you can do what you want to the system.

    This is why MS is trying to go secureboot and take these keys outside the OS. Since these keys are now outside the kernel your new target is not windows.

    That Exploit Guy
    –Actually, that’s a rhetorical question. Not testing the rootkit before releasing would just be downright stupid.–
    What do they have a Tardis or something that can time travel. The reality is the target is moving. So its not possible to test your rootkit to be sure that a kernel exploit will still be their or function how you expect. An update might have shot you. Since Linux does not crash often. A strange crash will draw attention.

    That Exploit Guy
    –What are the odds of someone running RHEL using the kernel package provided by Red Hat instead of compiling his/her own, you say?–
    This question what is the old that Redhat has updated their kernel since you made the exploit or change some policy files. In the case of changed policy files the kernel might be the same but the attack path might be death trap.

    This is the problem default distribution kernel and policies maybe updated. You have got in you are a one trick pony your screwed.

    That Exploit Guy most malware and viruses don’t primary hit the kernel on any OS. Its not required.

    –You are relying on the assumption that anyone wanting to mount such an attack will not take precautions against the LSM. That’s simply unrealistic.–

    There is a big different between Linux LSM and Windows security. Taking precautions against LSM undermines attackers possible effectiveness.

    That Exploit Guy I have an application running with Linux LSM granted permissions. How can application find out what those are. The answer is why SELinux and others cause applications hell at times. Is there is zero query function if application is allowed todo something. Attempt to access the policy file also can see application dead if LSM is there. So any syscall the application you broke into does not do you cannot use if you are avoiding the LSM. This will become default even without a LSM loaded as well. systemd is introducing seccomp filters to always be there no matter if the LSM is disabled or not. Next thing you cannot query if LSM is running if it is. Same issue you cannot query. To be correct systemd is worse you query due to cgroup you see a policy file that says you can do everything. One problem is a complete lie and just walked you into a death sentence.

    Taking precautions against the LSM is only use the functions the program you broken into uses. Like changing an ACL is your application LSM approved todo that. Maybe not since it does not do that. Now you list of workable attacks against each service drops massively.

    Microsoft Windows security permissions. Before every action I can query if I am allowed todo it. better the query raises no alarm at all. Microsoft makes attacking user-space too easy.

    So under windows due to stupid security design I can use ever function the application is allowed todo without fear of being killed instantly for doing something the application would not normally do.

    That Exploit Guy getting the kernel is simpler under windows because you can try everything. Linux causes you to presume that a LSM might be there, Might be active so you restrict your attack even on systems not running a LSM. So possible attack locations on Linux get left alone because the service the possible attack is in happens to be in a service without much privilege due to LSM. How does attack know if LSM is on or off at the other end.

    That Exploit Guy Linux Security Modules even that they are open source have correctly implemented security by obscurity. You want the attack not to know what is active and to be reacting on presumes.

    Precautions against the LSM in fact result in the attacker breaking into less systems than what were in theory possible to be taken. Yes LSM does not only protect those systems running it. It party protects those not running it by the security by obscurity effect.

    Joanna Rutkowska does not cover the kvm one. That is a different developer. I did not say that using kvm or xen were my ideas.

    –Now, about this supposed design weakness, which you spent countless words trying to pin it on NVidia, can you tell me exactly what it is and how you are going to exploit it, with code?–
    Its gpu instructions That Exploit Guy and I am not giving you the code of it. Because you should have found it. There are examples of GPU accelerated vnc and so on. You find they are doing something nasty. Open up a opengl buffer Push some gpu instructions into the gpu. Have output copied inside gpu back to the opengl buffer. Even better in the gpu you can choose to get only the changed parts. There is no security in the nvidia gpu forbidding this. Basically to the OS the attack is just a opengl game with a custom shader. I never trapped the screen from the OS point of view.

    It does apply to other makers of GPU’s. Just my machines are all Nvidia.

    The attack looks very much like a opengl game. There is a someone would be able to pull it off with direct x as well.

    The nvidia tegra 2 what is complete system breach is covered at the recent Linux Plumbers Conference or X11 conference. It was one them. By a Nvidia staff member saying sorry about it. Tegra 3 is design to prevent GPU being able to alter OS system memory. Still is not design to be multi user or to isolate application screen output from each other.

    It gets better in theory the screen capture can be done by webgl if it allowed memory operation shaders. So visit a website and a person can see everything that is on your screen.

    That Exploit Guy I was talking about digital signatures to access other servers and data on the system. With high enough privilege you can add your own approved signatures under windows to the update system or change the ones that are there.

    –The reason you need the password for the original private key (which you don’t have anyway) is completely beyond me.–
    Because the attack I am looking at is attacking a companies network.
    http://msdn.microsoft.com/en-us/library/windows/hardware/ff552275%28v=vs.85%29.aspx

    If you read you will find that company can add there own keys for drivers and there own extensions. The Microsoft Private key is not the only one that you can sign with. That Exploit Guy yes it possible to generate my own. This is the point once you have enough privilege you can even replace the Microsoft signing key and where the machine gets updates from. So now enable you to protect your exploited machine from being undone by windows update. This does not require hitting the kernel. Hitting the kernel might get you there sooner. Same is true for most update systems. Once you are high enough you can do what you want to the system.

    This is why MS is trying to go secureboot and take these keys outside the OS. Since these keys are now outside the kernel your new target is not windows.

    That Exploit Guy
    –Actually, that’s a rhetorical question. Not testing the rootkit before releasing would just be downright stupid.–
    What do they have a Tardis or something that can time travel. The reality is the target is moving. So its not possible to test your rootkit to be sure that a kernel exploit will still be their or function how you expect. An update might have shot you. Since Linux does not crash often. A strange crash will draw attention.

    That Exploit Guy
    –What are the odds of someone running RHEL using the kernel package provided by Red Hat instead of compiling his/her own, you say?–
    This question what is the old that Redhat has updated their kernel since you made the exploit or change some policy files. In the case of changed policy files the kernel might be the same but the attack path might be death trap.

    This is the problem default distribution kernel and policies maybe updated. You have got in you are a one trick pony your screwed.

    That Exploit Guy most malware and viruses don’t primary hit the kernel on any OS. Its not required.

    –You are relying on the assumption that anyone wanting to mount such an attack will not take precautions against the LSM. That’s simply unrealistic.–

    There is a big different between Linux LSM and Windows security. Taking precautions against LSM undermines attackers possible effectiveness.

    That Exploit Guy I have an application running with Linux LSM granted permissions. How can application find out what those are. The answer is why SELinux and others cause applications hell at times. Is there is zero query function if application is allowed todo something. Attempt to access the policy file also can see application dead if LSM is there. So any syscall the application you broke into does not do you cannot use if you are avoiding the LSM. This will become default even without a LSM loaded as well. systemd is introducing seccomp filters to always be there no matter if the LSM is disabled or not. Next thing you cannot query if LSM is running if it is. Same issue you cannot query. To be correct systemd is worse you query due to cgroup you see a policy file that says you can do everything. One problem is a complete lie and just walked you into a death sentence.

    Taking precautions against the LSM is only use the functions the program you broken into uses. Like changing an ACL is your application LSM approved todo that. Maybe not since it does not do that. Now you list of workable attacks against each service drops massively.

    Microsoft Windows security permissions. Before every action I can query if I am allowed todo it. better the query raises no alarm at all. Microsoft makes attacking user-space too easy.

    So under windows due to stupid security design I can use ever function the application is allowed todo without fear of being killed instantly for doing something the application would not normally do.

    That Exploit Guy getting the kernel is simpler under windows because you can try everything. Linux causes you to presume that a LSM might be there, Might be active so you restrict your attack even on systems not running a LSM. So possible attack locations on Linux get left alone because the service the possible attack is in happens to be in a service without much privilege due to LSM. How does attack know if LSM is on or off at the other end.

    That Exploit Guy Linux Security Modules even that they are open source have correctly implemented security by obscurity. You want the attack not to know what is active and to be reacting on presumes.

    Precautions against the LSM in fact result in the attacker breaking into less systems than what were in theory possible to be taken. Yes LSM does not only protect those systems running it. It party protects those not running it by the security by obscurity effect.

    Joanna Rutkowska does not cover the kvm one. That is a different developer. I did not say that using kvm or xen were my ideas.

    –Now, about this supposed design weakness, which you spent countless words trying to pin it on NVidia, can you tell me exactly what it is and how you are going to exploit it, with code?–
    Its gpu instructions That Exploit Guy and I am not giving you the code of it. Because you should have found it. There are examples of GPU accelerated vnc and so on. You find they are doing something nasty. Open up a opengl buffer Push some gpu instructions into the gpu. Have output copied inside gpu back to the opengl buffer. Even better in the gpu you can choose to get only the changed parts. There is no security in the nvidia gpu forbidding this. Basically to the OS the attack is just a opengl game with a custom shader. I never trapped the screen from the OS point of view.

    It does apply to other makers of GPU’s. Just my machines are all Nvidia.

    The attack looks very much like a opengl game. There is a someone would be able to pull it off with direct x as well.

    The nvidia tegra 2 what is complete system breach is covered at the recent Linux Plumbers Conference or X11 conference. It was one them. By a Nvidia staff member saying sorry about it. Tegra 3 is design to prevent GPU being able to alter OS system memory. Still is not design to be multi user or to isolate application screen output from each other.

    It gets better in theory the screen capture can be done by webgl if it allowed memory operation shaders. So visit a website and a person can see everything that is on your screen. That Exploit Guy fun right not even entered with any native code and possible know what anti-virus you are running and other protections.

    This exploit in the GPU’s is getting more serous as people are wanting to expose opengl to the web. So these hardware faults need to be fixed or shield against.

  15. That Exploit Guy says:

    @oiaohm

    ‘The system you are in may not be the one you want for starters. The user you are in as might not have the rights yet to allow you to attack kernel. Finally you don’t want to give away you presence quickly.’

    If you can allow a kernel module to install, then most certainly you have already got the required privilege to attack the kernel directly.

    We are still talking about SELinux, right?

    ‘Exactly stealing a digital signature + the password to activate it is faster. Remember there are lot digital signatures that are worthless without password matching. So attacker is required to stay in a system for long enough to collect the information of the password.’

    No, the digital signature is what you use to sign the bogus update package with. You want to fool the update system into believing that it is receiving a legitimate update, remember?

    The reason you need the password for the original private key (which you don’t have anyway) is completely beyond me.

    ‘Simple because you are a idiot and thinking all you have is screen. You did not just get the screen due to the design weakness you got the keyboard and mouse as well so you got the exact keystrokes the user typed.’

    OK. First off, let me keep a tally of how many time you have impolitely called someone an “idiot” without a due cause.

    Oiaohm unduely called someone an “idiot”: 1

    Now, about this supposed design weakness, which you spent countless words trying to pin it on NVidia, can you tell me exactly what it is and how you are going to exploit it, with code?

    ‘Screen capture is handy to work out where the user is entering data. xace covers input as well. Then you have scrapers for the stored account passwords.’

    So, at the end, this is a convoluted scenario in which you can make SELinux look somewhat useful and in which you have to steal the password of the account of a certain user, who coincidentally has the private key which he/she coincidentally locks with the same password for the update packages that he/she coincidentally dispenses.

    Just how many unlikely coincidents do we need to make this work?

    ‘Failing to break the kernel could alert the target they have a problem. Your plan completely depends on the kernel vulnerability to work. What happens if it does not.’

    What is the better chance that there is a 0-day vulnerability in the kernel than your little plan getting off the ground with all the stars aligned, you say?

    How about a much better chance?

    ‘You need the right set of conditions or you error.’

    What are the odds of someone running RHEL using the kernel package provided by Red Hat instead of compiling his/her own, you say?

    How about more likely than often?

    ‘Same thing. Harmless game monitoring you keyboard input waiting for you to do a important password. Trojan horse. It never did anything special. It just looks like a sloppy coded game that grabs the global keyboard and mouse and constantly monitors it.’

    Again, why grab the password instead of attack the kernel directly? To fulfill your terse, unlikely scenario?

    ‘If the security of the OS user-space is not solid going after the kernel is just wasting your time because you could have stolen all the information you require to commit crimes without needing a single kernel bug.’

    You are relying on the assumption that anyone wanting to mount such an attack will not take precautions against the LSM. That’s simply unrealistic.

    ‘That is a deeper problem. Yes it possible but it hurts. You are aware that kvm under Linux can trace a kernel OS that is contained. Same with xen.’

    Please don’t steal ideas from someone (reads: Joanna Rutkowska) who knows much more than you do.

    ‘Remember targeting a service that is a user space part if it fails you get to try again. Target ring 0 kernel mode and it fails kernel panic/blue screen and its game over.’

    I like how you go on and on about how someone would not attack the kernel because of kernel panic. Here’s a pop quiz: why would anyone not test his/her rootkit before sneaking it into someone’s else system?

    Actually, that’s a rhetorical question. Not testing the rootkit before releasing would just be downright stupid. Of course, as someone who claims to have better understanding than me on “how the people performing exploits are doing it [sic]”, you certainly would have known that, wouldn’t you?

  16. oiaohm says:

    Reality most nasty windows attacks break userspace get user to raise them to higher privilege somehow. Then install a new loader under the windows kernel so they can hide from the anti-virus. Stuff breaking the kernel security it was not required to get in and take the system.

    Why attacker can take multi attempts going the user-space path where the kernel can be one shot and it over.

  17. oiaohm says:

    That Exploit Guy
    –1) If you could gather such login details, then why not just used them take control of the system outright?–
    The system you are in may not be the one you want for starters. The user you are in as might not have the rights yet to allow you to attack kernel. Finally you don’t want to give away you presence quickly.

    –2) Forging a digital signature is not easy and usually takes a considerable amount of computational power that is simply not feasible for most people. If you can somehow manage to pull that off, then why not just make your bogus update look as legitimate as possible and let the rest take care of itself?–

    Exactly stealing a digital signature + the password to activate it is faster. Remember there are lot digital signatures that are worthless without password matching. So attacker is required to stay in a system for long enough to collect the information of the password.

    If you cause the kernel to crash the detection systems might be updated before you can get the password so you lose.

    –3) How is a string of “********” on the screen in any way useful for getting the password itself?–

    Simple because you are a idiot and thinking all you have is screen. You did not just get the screen due to the design weakness you got the keyboard and mouse as well so you got the exact keystrokes the user typed. Screen capture is handy to work out where the user is entering data. xace covers input as well. Then you have scrapers for the stored account passwords. Notice here attacker has not breached the kernel yet they have walked out with lots of data this include possibly enough to steal money from you.

    That Exploit Guy
    –As I have laid out in black and white for you, all that you need to do to completely obliterate your fancy little LSM is to spot a vulnerability in the kernel and attack it.–
    Failing to break the kernel could alert the target they have a problem. Your plan completely depends on the kernel vulnerability to work. What happens if it does not.

    Entering the system waiting for the user to enter a higher privilege password is more likely to go unnoticed. You don’t risk tripping alarms as much.

    Doing what a normal application can do also will go not noticed as much by any scanning software.

    That Exploit Guy
    –The city of Troy fell under the hand of the Greeks because they opened their gates to bring in a wooden horse full of enemy soldiers. This concept of a “trojan horse” is not really that hard to grasp, is it?–
    Same thing. Harmless game monitoring you keyboard input waiting for you to do a important password. Trojan horse. It never did anything special. It just looks like a sloppy coded game that grabs the global keyboard and mouse and constantly monitors it. This is in fact not strange with cheap windows games to fail to let go of the keyboard and mouse.

    Data thief has no requirement that the kernel is defeated. Only that the security system is defeated.

    That Exploit Guy do most coding bugs say it will work every single time. Mostly no it don’t. You need the right set of conditions or you error.

    Attackers against windows are not required to take on the kernel at all. So most don’t.

    That Exploit Guy you are right the focus should be on the kernel if the security of the OS is solid.

    If the security of the OS user-space is not solid going after the kernel is just wasting your time because you could have stolen all the information you require to commit crimes without needing a single kernel bug. Also the information you stole by not going after the kernel would allow you to worm on to other systems like banks where the money is.

    That Exploit Guy I said SELinux forces the attackers to target the kernel where is higher risk.

    That Exploit Guy
    –Again, you are expecting the kernel to tell you if the kernel is working correctly.–
    Of course I have not entered into the methods you can use to secure a kernel.

    That is a deeper problem. Yes it possible but it hurts. You are aware that kvm under Linux can trace a kernel OS that is contained. Same with xen.

    A breach in kernel can be mitigated against to a point. First I have to force the attacker to go after the kernel. Then I can defend it.

    This is the art of war. You need to force your enemy to be where you want them to be.

    Remember targeting a service that is a user space part if it fails you get to try again. Target ring 0 kernel mode and it fails kernel panic/blue screen and its game over.

    That Exploit Guy targeting the kernel in ring 0 is a lower success rate option to get the data. Attackers will avoid the attack kernel option unless forced in most cases due to the fact failure is game over.

    That Exploit Guy really for a so called Exploit Guy you have zero understanding of how the people performing exploits are doing it. So you don’t get the attackers only target the kernel if they have to.

    You need the OS to make them have to.

  18. That Exploit Guy says:

    @oiaohm

    ‘If the system believes it is being told to apply an update. The user approves it the system believes. Because the interface could be captured. Say by by.’

    If I understand correctly (and I hope you do realise that your barely intelligible rambling is agonising to read), what you are trying to say is that you want to gather the login details of an administrative account by screen capturing, then trick the update mechanism, be it yum, apt, or Windows Update, into believing that it is receiving a legitimate update and then approve the bogus update with the stolen identity. Is that correct?

    This is all very interesting, though with the several glaring problems:

    1) If you could gather such login details, then why not just used them take control of the system outright?

    2) Forging a digital signature is not easy and usually takes a considerable amount of computational power that is simply not feasible for most people. If you can somehow manage to pull that off, then why not just make your bogus update look as legitimate as possible and let the rest take care of itself?

    3) How is a string of “********” on the screen in any way useful for getting the password itself?

    ‘It is many times simple to compromise the security to get to a point to attack a kernel if you can take control of the user. Because the user is able to approve actions that should be rejected.’

    An easier way would be to just drag the user into a dark alley and then steal his wallet. Why go through such length to do all these redundant things that serve no obvious benefits when you can get immediate results with a club to the head?

    ‘In fact security threat does come from normal usage of a system at times. Like installing a new device with a new driver. When attack can take control of user they can at times do this.

    ‘This is why you need multi levels of security.’

    Again, you are expecting the kernel to tell you if the kernel is working correctly. Even ignoring the fact that you are talking about one of the many attack vectors that SELinux does nothing to protect against, your assumption that MLS can somehow exist within an amorphous thing in memory called the “kernel” is simply flawed.

    ‘I don’t need a bug in the kernel if I can get the user to install my code into kernel space or worse as the loader of the operating system.’

    ‘Not all attack come from altered programs. Some come from trojans.’

    Interesting, but entirely irrelevant to SELinux or any LSM.

    The city of Troy fell under the hand of the Greeks because they opened their gates to bring in a wooden horse full of enemy soldiers. This concept of a “trojan horse” is not really that hard to grasp, is it?

    ‘That Exploit Guy problem here you are kernel focused.

    ‘The reality is the kernel alone will not make an OS secure. To download a database with all your records does not require an attacker to breach kernel.’

    This is patently absurd. When you have your entire security model enforced by the kernel, how can you possibly say with a straight face that the focus should not be put on the kernel? As I have laid out in black and white for you, all that you need to do to completely obliterate your fancy little LSM is to spot a vulnerability in the kernel and attack it. This has been the case for as long as Red Hat has thrown around terms like “MAC” and “MLS” in their brouchers. Don’t kid yourself – there is nothing in SELinux that genuinely protects the kernel itself in any way, and in your little scenario, whatever you built on it is just as good as a house of cards.

  19. oiaohm says:

    That Exploit Guy Little point by the time the attacker is normally to the kernel for a person like me. Critical information could have already been stolen. The ability to run a program in the first place is a problem.

    You wish to lay trip lines and hope they hit them before they get away with anything.

    Kernel fault to me is last level of problems. Its a critical problem yes but it not the only problem.

  20. oiaohm says:

    That Exploit Guy

    –Once you have compromised the kernel, you get full control of the system. Do I still need to worry about how to get someone else’s screen? Of course not!–

    True but you have to get to that point.

    Can you compromise a kernel without the kernel containing a security flaw and the userspace not policed when I enter the system. Most cases yes.

    If the system believes it is being told to apply an update. The user approves it the system believes. Because the interface could be captured. Say by by.

    It is many times simple to compromise the security to get to a point to attack a kernel if you can take control of the user. Because the user is able to approve actions that should be rejected.

    –A security threat does not come from normal use of the system.–

    In fact security threat does come from normal usage of a system at times. Like installing a new device with a new driver. When attack can take control of user they can at times do this.

    This is why you need multi levels of security.

    I don’t need a bug in the kernel if I can get the user to install my code into kernel space or worse as the loader of the operating system.

    Not all attack come from altered programs. Some come from trojans.

    –SELinux is not designed to prevent that.–
    Is design to prevent it if configured correctly.

    You are right about too much configuration required to get to a secured OS.

    I never said that you could operate Selinux without bureaucracy. Part of selinux is that bureaucracy.

    Lot of the faults like user side channel attacks can be prevents without requiring as much bureaucracy. Mostly by taking way options from default.

    Its not just the kernel that needs work. This is the reality. Userspace applications expecting to be able to what ever. Reality security cannot work that way.

    Its also like idea user space drivers solve everything. If you don’t have proper isolation against going side ways a user space driver can be worse than a kernel one. Why there is a file system driver in userspace you now can alter everything appearing to come from the file system.

    In fact a user space driver OS need better user land sand-boxing in the core kernel.

    –It is not even meant to follow any particular principles, let alone detecting threats.–
    No anti-virus under windows is required to follow particular principles either.

    That Exploit Guy problem here you are kernel focused.

    The reality is the kernel alone will not make an OS secure. To download a database with all your records does not require an attacker to breach kernel.

    Kernel is only one area of problem. User land weaknesses in isolation is another.

    How do you know someone is a twit about security. They are solo kernel focused so fail to secure the user space code. Like openssh bug that was not kernel space. Allow user to login as admin with high privilege. As admin without other security and without breach the kernel could download all the data out the server.

    User space permissions and controls are just as critical and kernel space.

  21. That Exploit Guy says:

    @oiaohm

    ‘How many applications need to be able to take a screen capture or see where the mouse is on the screen at all times?’

    You are still obssessed with screen capture.

    You have applications executed by someone else running on your server.

    You have a kernel with unpatched vulnerabitilies, known or unknown.

    Once you have compromised the kernel, you get full control of the system. Do I still need to worry about how to get someone else’s screen? Of course not!

    There, is that easy enough for you to understand?

    ‘The question with LSM is a layer. The question is if you can use said bug or will LSM due to syscall filtering stop you dead. Selinux running strict use a syscall the application is not registered to use will see application terminated.’

    Again, you are relying on the kernel to tell you if the kernel is doing what it is supposed to do. Do you see the problem here? Any bug or misconfiguration in the kernel can potentially lead to privilege escalation with or without your fancy little LSM being able to prevent it. That’s why we call that a bug or a misconfiguration, genius.

    ‘The LSM is basically the Linux anti-virus.’

    No. The sole purpose of the LSM framework is to provide a common platform for the implementations of security models. It is not even meant to follow any particular principles, let alone detecting threats.

    ‘This does not mean its not effective at stop some threats dead.’

    A security threat does not come from normal use of the system. There is no reason to expect that an attacker will attempt to compromise the system by trivially using syscalls in predictable manners. That’s stupid. You might as well just put a “don’t hack me” sign on everyone’s terminal, because that’s about as effective as SELinux in preventing a breach.

    ‘What I am refering to is not like covert channel. Its not a secret channel. Its a channel that is not protected. Side ways exploit. You have the permission to read the screen, keyboard and mouse and you have nothing that stops you from capturing everything on most operating systems.’

    It’s call a “side-channel” attack, dear. Also, no, SELinux is not designed to prevent that.

    ‘NSA extended could to a point with hacks.’

    Government agencies such as NSA and DoD usually have mountains of security policies to establish who has access to what and when and how. Even if you are cleared to access certain top-level secrets, you are usually only allowed to do so within an isolated environment with dozens of eyes watching your every move. SELinux is just something created to meet this kind of bureaucracy. If you think you can take away the bureaucracy itself and fit SELinux back into your environment without it losing its effects, your are sorely mistaken.

  22. oiaohm says:

    One of the interesting side effects of xace and fixed up is xeyes. It don’t work any more. Its about the only application serousally effected.

    Sandboxing does not have break much if the applications normally don’t use those features anyhow.

    The reality is applications are given way more permission then they really need to operate. Too much in the sense they can high jack other applications.

  23. oiaohm says:

    –Do you mean “covert channel”? No, SELinux has no means to protect against such things.–

    I did not say covert channel. I did not. xace deals with a particular issue. Without it. You run 2 applications. Both get access to screen. Both can screen capture and keyboard and mouse capture.

    That Exploit Guy
    –By creating a flimsy, trivial sandbox that messes up the functionality of normal application and is completely inept at preventing attacks directed at the kernel.–

    How many applications need to be able to take a screen capture or see where the mouse is on the screen at all times?

    When you answer this the number of effected applications is bugger all.

    This is the fault I am referring to. Want a working example on Windows load up vnc. Do you have to grant VNC any special rights to capture the complete screen and insert keyboard and mouse events.

    Answer no you don’t. xace enabled X11 you had to. Because screen capture is not possible without permission.

    The simple reality here a selinux system running with selinux fully on reduces vectors.

    –Does an LSM mean anything if I can use said bug or misconfiguration and disable it outright?–

    The question with LSM is a layer. The question is if you can use said bug or will LSM due to syscall filtering stop you dead. Selinux running strict use a syscall the application is not registered to use will see application terminated. If it set on max strict it will terminate everything links to that entry path into the system. So you attack could be completely dead. The service you got in on might never restart. So the attack vector you used is now dead.

    The LSM filter from userspace to kernel space is a strict feature.

    Misconfiguration is a issue with LSM. This is why I called xace a hack. Its working around a design flaw with risk of Misconfiguration.

    The same arguement people use to try to say I should not run a anti-virus. That Exploit Guy. The LSM is basically the Linux anti-virus. Just like all anti-viruses its not 100 percent. This does not mean its not effective at stop some threats dead. In a lot of ways an LSM is more effective than you conventional anti-virus.

    Wayland by default application cannot see mouse or keyboard once mouse or keyboard leaves the applications window. Application without permission to screen capture can only capture a picture of their own windows. For receiving keys when there windows is not active they have to register with wayland compositor that can even change the key assignment.

    All this without requiring xace. This will come into X11 in time. X Windows has a permission problem in the GUI allowing screen, keyboard and mouse to be captured by anything running. Same problem applies to MS Windows.

    What I am refering to is not like covert channel. Its not a secret channel. Its a channel that is not protected. Side ways exploit. You have the permission to read the screen, keyboard and mouse and you have nothing that stops you from capturing everything on most operating systems.

    NSA extended could to a point with hacks.

    Windows has other side ways exploits Where you can attack stuff at the same security level as you.

    The goal of selinux is to prevent side ways exploits. So I run X application due to flaw in X and X getting defeated it cannot go straight sideways to Y and take control of Y application as well. The attacker is now forced to come to kernel and attack kernel.

    This is one layer of protection.

  24. That Exploit Guy says:

    @oiaohm

    I don’t think there is any need for me to pay attention to you in any way after your barrage of insance, rupulsive rambling about IBM trying to minimise death in the Holocaust while profiting from it at the same time, but given that you are hardly the only one sipping Red Hat’s Kool-Aid, I’ll give you the dressing down this time you have always wanted.

    ‘Screen snooping on ssl linked terminal servers is not simple.’

    No one is talking about screen snooping, oiaohm. Regardless of the protocol in question, you are running applications remotely executed by someone else on the server. I think that in itself is worth worrying about.

    ‘SELinux is not a trivial design. SELinux is designed for user-space starting attacks. Its only one of many layers of defence.’

    And none of those “layers of defence” are worth anything if the kernel remains shared and vulnerable for the most part. There is simply no containment to speak of when one side of your lion cage is made out of sallophane, and that’s SELinux in a nutshell.

    ‘That Exploit Guy there is nothing in Windows like this. Selinux tracks the resource through the X11 server to when it gets to kernel and back.’

    Again, none of this means anything if I can go straight in to the kernel and disable your entire LSM outright. All those fancy auditing features are essentially useless as long as the kernel remains a vulnerability in itself. You seriously need to stop regurgitating the marketing nonsense Red Hat put on their brouchers and start thinking in terms of how a government agency such as NSA would use SELinux in their own context.

    ‘Yes the Nvidia lack of memory control fault exists on windows. You can do a complete screen capture from opengl even in Windows 7 using GPU instructions.’

    Now you are just drifting off to an irrelevant tangent. A bug in the kernel can occur any time and anywhere. At the end of the day, your system is vulnerable to attacks regardless of where the source of the problem is. The only thing we are looking at is how effective SELinux is in such circumstances, and as far as I can see, it just won’t help much at all.

    ‘Most people were not using selinux with xace in X11 on Linux so side ways exploits on local usage have been massively possible.’

    Do you mean “covert channel”? No, SELinux has no means to protect against such things.

    It’s painful enough to read your rambly creative writing. Don’t make it any more difficult than it is by butchering terminology that an educated individual should have got right in the first place.

    ‘Also x86 performance its you not being in ring 0 this is why user-mode drivers have not taken off.’

    Here, let me help you with this. It’s pitiful to watch you desperately trying to look for the proper words to describe something this basic, and, boy, am I not feeling generous today!

    The proper term you are looking for here is “context switching”. When the CPU goes from one task to another, that’s a context switch, and it comes with a performance penalty. On top of that, when you jump between ring 0 (kernel mode) and and ring 3 (user mode) on an x86 CPU, an additional performance penalty is also added to the context switch. In the case of a video driver, performace is entirely dependent to how you manage the switch between the two security levels since at some point you must switch between the application and the kernel in order to put the graphics on the screen.

    The Windows Display Driver Model employs both the user and kernel spaces, by the way.

    ‘That Exploit Guy really most likely did not understand what you were reading.’

    If by understanding you mean “regurgitating” and by “what you were reading” you mean “Red Hat product brouchers”, then you are absolutely correct.

    ‘There is also another interesting fact. Lot of Linux so called core code fault is common code shared between drivers. Common code windows does not provide so drivers ship with there own copies of it so expanding exploit surface area.’

    I know it’s futile to ask you for proof but, if you don’t mind, would you provide examples with code for both Windows and Linux? I am not a big fan of sketchy hand-waving, and I don’t see why I should become one now.

    ‘The protection is missed. Turning it on shuts down a lot of Linux kernel attacks. Loadable modules with this option on never are full rw.’

    You are drifting farther and farther away from the discussion, and I am tired of that.

    Does it matter what bug or misconfiguration it is and what causes it if what it means is your kernel being vulnerable to attack?

    Does an LSM mean anything if I can use said bug or misconfiguration and disable it outright?

    Your religious belief in SELinux being any more than NSA’s bureaucratic play-thing is quite frankly symtomatic to those who has never looked beyond the hype generated by Red Hat, and as long as you keep fluffing about this sort of irrelevant stuff, you are showing more that you simply don’t understand the subject matter at all.

    That Exploit Guy not all issues are kernel level. Some are the way the userspace is design. The GUI secuirty starts in user-space design. This selinux was able to patch over in Linux.

    By creating a flimsy, trivial sandbox that messes up the functionality of normal application and is completely inept at preventing attacks directed at the kernel.

    Very cute, oiaohm. That’s very cute.

  25. oiaohm says:

    Chris Weig LOL.

  26. Chris Weig says:

    Peter, your shift at Australian Bush Burgers is starting. What are you still doing here?

  27. oiaohm says:

    That Exploit Guy
    –There is nothing specific in the article about X window system because there is nothing specific in need to be addressed about it. In any case, if the kernel is vulnerabilible, the “client” processes running under it will also become vulnerable to attacks in one way or another. I suggest you go and read the article before giving me another ill-informed, knee-jerk response.–
    Yet vulnerabilibles don’t only appear in the kernel space. Capturing graphical output is a 3 level problem.

    The means to capture complete screen start with Userspace. The come userspace interfaces to kernel then become hardware design.

    It is a fault that effects all 3 levels. That has to be addressed at 3 levels.

    That Exploit Guy remember to attack you have to get past all the layers of security. Most kernel flaws alone are not enough to breach a server.

    Please not the date of the pbs one. That is pre the module security fix.

  28. oiaohm says:

    That Exploit Guy to be correct he is right.

    Screen snooping on ssl linked terminal servers is not simple.

    The local access issue is a major fault.

    –trivial sandboxing like SELinux–
    SELinux is not a trivial design. SELinux is designed for user-space starting attacks. Its only one of many layers of defence.

    http://www.nsa.gov/research/_files/selinux/papers/xorg07-paper/node4.shtml
    That Exploit Guy there is nothing in Windows like this. Selinux tracks the resource through the X11 server to when it gets to kernel and back.

    Horrible yes. I do agree this is an hack to get on top of applications and users snooping on each other.

    Most people were not using selinux with xace in X11 on Linux so side ways exploits on local usage have been massively possible. The update will see xace not required to prevent a class of attacks on Linux. Yet the same class of attack will still exist on windows allowing like remote installed vnc to watch user actions and wait for correct point to attack.

    This is without all the other possible kernel exploits That Exploit Guy that windows and linux have. Windows mostly due to not properly audited third party drivers.

    Yes the Nvidia lack of memory control fault exists on windows. You can do a complete screen capture from opengl even in Windows 7 using GPU instructions.

    That Exploit Guy by the way go back and read that link you gave again.

    http://code.google.com/p/raksha/ option requires altering the hardware. x86 hardware is not designed for security constructs in ring 0. Also x86 performance its you not being in ring 0 this is why user-mode drivers have not taken off.

    They are Linux security features that are not used that can be used to make the system even harder.

    That Exploit Guy really most likely did not understand what you were reading.

    Also that white paper tells you the current UEFI secure boot thing that is a secvisor is beatable.

    Interesting enough did not cover turning red zoning, Sanity checks, Poisoning, and user tracking of memory on in the memory management. That user tracking shuts down a lot of attacks.
    http://www.mjmwired.net/kernel/Documentation/vm/slub.txt
    Yes the Linux default allocate contains some BGI. Problem is by default it ships off due to performance overhead. Windows also ships with its BGI turned off so Linux is not alone doing this. Yet all those features are build into every default built kernel of Windows and Linux.

    That Exploit Guy yes that item you quoted missed a basic.

    There is also another interesting fact. Lot of Linux so called core code fault is common code shared between drivers. Common code windows does not provide so drivers ship with there own copies of it so expanding exploit surface area.

    That Exploit Guy black hats write far better documentation on the topic. Truly comparing windows to Linux to OS X. Really you did not want to bring one of those in. Because it does not show Linux as that weak.

    There is a minor error in some black hat talks.
    http://cateee.net/lkddb/web-lkddb/DEBUG_SET_MODULE_RONX.html
    The protection is missed. Turning it on shuts down a lot of Linux kernel attacks. Loadable modules with this option on never are full rw.

    Remember this RO/NX stuff is end of 2010 it enters the Linux kernel. Its another thing that kills of lot of those exploits. Once that is enabled there is no such thing as in Linux kernel space of executable and read write memory. Fault that windows and OS X driver loader still has.

    Of course some distributions should be got up for not enabling RO/NX in default kernels.

    That Exploit Guy not all issues are kernel level. Some are the way the userspace is design. The GUI secuirty starts in user-space design. This selinux was able to patch over in Linux. Windows userspace design is still flawed. Then goes all the way down to hardware design issues.

    The particular issue of NT not being multi user is Userspace design errors. Linux has not been above all these errors.

  29. That Exploit Guy says:

    ‘Nothing in there about X window system so I suppose you agree with my evaluation.’

    There is nothing specific in the article about X window system because there is nothing specific in need to be addressed about it. In any case, if the kernel is vulnerabilible, the “client” processes running under it will also become vulnerable to attacks in one way or another. I suggest you go and read the article before giving me another ill-informed, knee-jerk response.

    ‘Symantec most-attacked vulnerabilities in 2011: Top 4 go to that other OS’

    I didn’t notice there was a score-board for how often a vulnerability is exploited. Is that for a drinking game or some social event of a similar nature? That’s about all the useful purposes I can think of for such a thing.

    Of course, hell will probably freeze over when you, Mr. Pogson, starts pondering on the actual implications of a vulnerability rather than keeping such worthless scores.

  30. Link was broken. Fixed it for you.

    Nothing in there about X window system so I suppose you agree with my evaluation.

    “This paper’s study of Linux kernel vulnerabilities suggests that
    we have a long way to go in making existing OS kernels secure.
    First, from January 2010 to March 2011, 141 vulnerabilities in the
    Linux kernel were discovered, many of which have serious exploits.”

    Good. The kernel boys and girls will not be unemployed any time soon.

    Symantec most-attacked vulnerabilities in 2011: Top 4 go to that other OS

  31. That Exploit Guy says:

    ‘I don’t see it that way. In GNU/Linux, if the applications are on the terminal server and the users and their Xservers are on the thin clients, the users cannot spy on each other if they are not using hubs. The processes cannot spy on each other.’

    Pogson spins a yarn. Nobody is surprised.

    It seems that your knowledge in this matter is mostly from the following three sources:

    1) Wikipedia/Internet
    2) oiaohm
    3) What people you dislike have told you about.

    The first two are as unreliable as they can get, and the last one is what you constantly try to get rid of from your blog despite being more knowledgeable than you in most cases. Forget about shill cheques – it is your ignorant and bigoted attitude towards subject matters that take one years of serious study to understand that draws you all the unwanted attention.

    Oh, in case you actually want to learn about operating systems vulnerabilities, here’s something to get you started.

    Alternative, you can continue to listen to oiaohm spouting more uneducated opinion on flimsy, trivial sandboxing like SELinux. The choice is yours.

  32. oiaohm wrote, “It a history design weakness of all OS’s.”

    I don’t see it that way. In GNU/Linux, if the applications are on the terminal server and the users and their Xservers are on the thin clients, the users cannot spy on each other if they are not using hubs. The processes cannot spy on each other. That’s way more secure than M$ was at the start.

    “In December 2002, Microsoft issued a patch for Windows NT 4.0, Windows 2000, and Windows XP that closed off some avenues of exploitation.”

    That was as late as 2002 and covered NT, 2K and XP.

  33. oiaohm says:

    That Exploit Guy yes you are right to say its a myth that NT was design to be single user.

    But there is a problem. When it comes to local graphical that system was not design multi user.

    Linux itself has had that problem as well.
    http://www.phoronix.com/scan.php?page=news_item&px=MTE5NDk

    It a history design weakness of all OS’s. There were hacks in Linux to closed the vectors down.

    Windows Vista introduces session wrapper around services so they cannot snoop on everything(in theory). Up until that point there was really only 1 local output device. XP the switch user a background service could broadcast what was on screen at all times. Even now this is still possible because services can be running with a privilege that allows it to pull this off.

    Selinux hardened could prevent X11 having this issue. But desktop users did not like running this.

    Now after the software stacks are fixed it still leaves video cards that sux in design for security.

    That Exploit Guy reality the graphics hardware in most desktops are build from are not designed to be multi user because Microsoft never demanded features to make it such. This feature includes in GPU memory manager to prevent different code in the GPU accessing other code memory.

    If you want the example of worse nvidia tegra 2. The gpu on that can write anywhere in ram without permission. Tegra 3 introduces a memory controller between system ram and gpu. Does not introduce a proper internal memory controller to the Tegra. Yes it just brought it into line with your general desktop Nvidia chips.

  34. That Exploit Guy says:

    @Robert Pogson

    ‘For me, the operating system is the last line of defence in IT. If it was designed to be single-user, designed by salesmen, and forced on people in an uncompetitive market, the results will be disastrous.’

    Way to regurgitate the same myth that NT was designed to be single-user! Are you sure you aren’t working to become a modern-day “investigative” journalist – one that never does any fact-checking and has his entire corpus of work mostly copied from somewhere else?

    ‘All the people locked into IT with M$ and pressuring others to repeat the mistake is a similar technological failure.’

    Again, that totally doesn’t sound like someone is just throwing his dummy out of the pram because the world fails to see that they are wrong and he is right!

    Stop being such a child, Mr. Pogson.

  35. TFA is tangentially about food-safety. It’s mostly about the failure of technology no matter how well intended/policed/enforced. Bad things happen and they can happen in the worst possible ways. It’s always good to have a backup plan. It’s a case where half a dozen people and organizations had the opportunity to do the right thing but failed. All the people locked into IT with M$ and pressuring others to repeat the mistake is a similar technological failure.

  36. kozmcrae wrote, “over cooked in the microwave “.

    I disagree. That would harm microwave ovens everywhere. I think the cursed CDs should be shredded. Even a good pair of scissors are better than nothing. I’ve seen them done in with sand-paper too.

  37. Chris Weig says:

    In an article about failures in a beef processing plant and food safety?

    You should’ve noticed by now that by means of long-winded, pointless, boring analogies Mr. Pogson manages it like no other to turn nearly every article into a Debian GNU/Linux recommendation. Because, clearly, Debian GNU/Linux works for cooking beef.

  38. Mongrol says:

    “For me, the operating system is the last line of defence in IT.”

    In an article about failures in a beef processing plant and food safety?

    http://dictionary.reference.com/browse/tenuous

  39. kozmcrae says:

    I agree, all Microsoft CDs should be over cooked in the microwave before installation to make sure no malware survive.

Leave a Reply