* Posts by Down in the weeds

10 posts • joined 1 Aug 2014

Level up Mac security, and say game over to malware? System alerts plus Apple game engine equals antivirus package

Down in the weeds
Big Brother


(inter) active policy enforcement by monitoring exactly what those 1s and 0s are doing deep in the guts, neat approach

I think there might be a high correlation between Mac fanbois and highly libertarian privacy pedants who will react in horror to the development of yet-another line in spyware

Data-spewing Spectre chip flaws can't be killed by software alone, Google boffins conclude

Down in the weeds

Harvard Architecture, Anybody?

Completely separate(d) Instruction memory and Data memory. Some (very careful) admittance to reading I memory for fixed constant values. Multiple independent D memory 'banks', each with explicit different interface connections for both address and data connections per-bank. Multiple internal independent D caches, one per bank. instruction set support for hardware-based copy-on-write (write multiple D banks from a single I thread). Just some thoughts ...

Intel's Software Guard caught asleep at its post: Patch out now for SGX give-me-admin hole

Down in the weeds

So disappointing

When I first learned of Intel hardware support for application level 'enclaves' I was hopeful. Yet again the implementation is a mixture of hardware and software and the latter component is frail.

Between you, me and that dodgy-looking USB: A little bit of paranoia never hurt anyone

Down in the weeds

Re: It's called a linux PC.

This is too simplistic and generalised; not all Linux are equal. All Linux are reconfigurable, even to the extent that some Linux do not include USB kernel modules (the paranoid option). For those that do, a careful crafting of rules in 'udevs' is necessary to create the appropriate behaviours*. Further, given deeply meaningful knowledge of the Registry, even Windoze can be configured to mount the volume of a USB storage device in a 'sandbox' and not assume that any executable in the contents of the sandbox should be executed without inviting the external (responsible?) human to so approve.

*So, what to do about USB devices that are *not* storage devices? A faker USB device that is to all intents a 'keyboard' that squirts "go to attacker's hell-hole web site now" in the direction of your web browser at USB wire speed?

Spectre-protectors: If there's something strange in your CPU, who you gonna call?

Down in the weeds

Cease and desist destroying English

What an awful sentence construction: "The site isolation design document explains that the Spectre mitigation sandboxes site renderer processes." I had to re-read this three times to understand whether or not there was an absent verb following 'that'. Then it dawned on me: the author is employing the foul Merkin habit of reusing a noun as a verb, in this case 'sandbox'.

Even the Merkin online www.dictionary.com provides this:


1.a box or receptacle for holding sand, especially one large enough for children to play in.

2.Computers. an environment in which software developers or editors can create and test new content, separate from other content in the project (often used attributively): "

Please, please, please can the Editors enforce a policy of 'English(UK)' only?

Juniper scores dubious honour of owning CVE-2018-0001

Down in the weeds

Etherleak again - really??

Oh! For! Pity's! Sake!

This really does reinforce the view that software security, or perhaps 'making secure-enough software' is NOT a professional engineering discipline. The consequence of which is that there can be very little confidence that any vulnerability or flaw of any vintage once detected and thought to be fixed cannot be though of as 'eradicated'. There really is no commonly-held body of knowledge; the need to repeat the mitigation for repeated commitment of software sin will act as a drag anchor to any notion that the general level of skill and competence increases with the passage of time.

Big Bang left us with a perfect random number generator

Down in the weeds

So 20th Century

>>"These days it's common to use the thermal noise generated by a zener diode"

une chapeau ancienne

These days we exploit the meta-stability of ring oscillators, especially inside all digital devices

NIST to hypervisor admins: Pro-tip, secure your systems

Down in the weeds

Typical lack-of-Configuration-Management - AGAIN!

Oh dear

NIST SP 800-125 ALREADY exists at Issue 1 titled

"Guide to Security for Full Virtualization Technologies", published in January 2011

This draft for comment SP 800-125A (emphasis the A) is

a) narrower in scope

b) probably necessary

c) relays some tarmac on existing nighways & byeways

d) worth responding to at least in order to offer soe 'lexical continuity' in the language of the 'recommendations (generally engineers do not know how to respond to a text tht calls itslef a requirement but uses terminaology like "It would be really nice if <thing> did <this kindofa-function>

Linux kernel devs made to finger their dongles before contributing code

Down in the weeds

Security Policy anyone?

Is there a (formal, written) Security Policy for kernel devs?

Are the Linux Foundation considering developing such a thing?

How do we gain assurance that all kernel devs possess a *genuine* Yubikey

Seems to me these are USB 'automatic keyboard' devices, a la the 'USB is universally hacked / hackable' scenario

A modicum of increased confidence in the integrity of kernel modules arises from this 2FA ...

... just a tad

Plug and PREY: Hackers reprogram USB drives to silently infect PCs

Down in the weeds

USB 'firewall'

Yes, udevs rules in Linux help but are not the complete answer to 'USB firewall', as Peter Gathercole points out, spoofing USB devices will malicioulsy provide legitimate Product ID and Vendor ID strings.

Nobody seems to have cottoned on to the fact that use of USB devices is inherently risky BY SPECIFICATION. The USB specification mandates that OS kernels (all of them) instantiate low level drivers upon detecting the connection of a USB device.

USB mass storage devices with on-stick µC are way more difficult to mitigate.

Being truly nerdy I once watched the Linux kernel generte all of: 'sgx', 'sdy' and 'sr0' upon connection of an Imation IronKey (sg is SCSI generic, sd is the flash mass storage bit & sr is a pseudoCD on the IK wherein stored all the code: no µC on the IK)

In Linux we can write udevs rules to 'white list' only those USB devices that we (would wish to) 'trust' by PID, VID (and even down to the granularity of Serial# if such is included in the USB parameter block offered by the device).

In Windows we need a COTS bolt-in to achieve the same function (because the Windoze Registry obfuscation of where the USB device Class and device-specific USB parameter block is stored is heinous and the coders of the COTS bolt-on have done all that 'heavy lifting' for us).

Then, to truly 'trust' the device you need to take the executable from a Known Good* one and 'fingerprint' it, e.g. take the SHA-256 hash of it.

Now, 'adopt' the executable -include it in your own software (which of course you measure before invoking, including measureent of the 'adopted' USB exe)

Then, adjust udevs rule to point to a script that ensures the 'internal' exe is invoked not the 'on stick' exe

I am not sure how this last bit is accomplished on M$, but a PowerScript guru would achieve it

* i.e. not 'as previously enjoyed by NSA' & not using on-stick µC

Biting the hand that feeds IT © 1998–2019