"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'?
15 posts • joined 1 Aug 2014
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."
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).
(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
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 ...
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?
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?
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.
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>
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
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