* Posts by Down in the weeds

15 posts • joined 1 Aug 2014

Rust in peace: Memory bugs in C and C++ code cause security issues so Microsoft is considering alternatives once again

Down in the weeds


"Thomas's point, though, is that preventing memory bugs is a burden on developers", so hang on a cotton-picking minute: developers are expected to not even *think* about what they are doing? this *thinking* stuff is a 'burden'?

ReactOS 'a ripoff of the Windows Research Kernel', claims Microsoft kernel engineer

Down in the weeds


complainer actually Cleans Their Xi

Who cares about a Soyuz launch or a Vega delay when there's space gin to be had?

Down in the weeds

Show Me the Space Gin!

Tidy little marketing sideline

Two pentesters, one glitch: Firefox browser menaced by ancient file-snaffling bug, er, feature

Down in the weeds

Was it just me?

I saw: "not as strict as we wanted it to be due to compatibility issues"

I read: "not as strict as we wanted it to be due to complacency issues"

Mystery GPS glitch grounds flights, leaves passengers in the bar

Down in the weeds

Horse & Cart? Cart or Horse??

In which direction does causality's arrow fly?

"However, and alarmingly, it appears that the GPS system is having a bit of a wobble as far as certain types of ADS-B hardware is concerned"


"GPS satellites received a software upgrade that has left the system borked as far as the receivers on Rockwell Collins' gear is concerned"

Nope & nope

The 'GPS system' is not borked. The GPS signal as upgraded is no longer available to / correctly processed by unmodified receiver equipment; rendering the onward system - ADS-B - borked

Aircraft type is irrelevant

"The aircraft types affected include some Airbus A320s, the Boeing 737-900 and Bombardier CRJ 700 and 900."

Who cares?

The position of the aircraft reported into ADS-B is mostly the position of the GPS receiver system fitted (actually the electrical centre of the antenna)

Although, strictly speaking: "The source of the state vector and other transmitted information as well as user applications are not considered to be part of the ADS-B system" (URL: https://en.wikipedia.org/wiki/DO-242A); it is FAA mandate that GPS is used in source data to compute the state vector (URL: https://www.faa.gov/news/fact_sheets/news_story.cfm?newsid=7131).

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–2020