That may work for the serial port (if it actually includes a MAX232 voltage level converter, which is not guaranteed).
Not for the parallel port. Those usb-parallel adapters are actually emulating a USB printer -- they're absolutely worthless if you want to use them to bitbang microcontrollers and other such things.
In fact, they're absolutely worthless overall -- when did you last see a printer that doesn't support USB?
As if the xml/xul/xpcom repetitive cargo cult nighmare wasn't bad enough.
Just as the code started to mature a little bit, and despite its ugliness and brittleness, people started to make (a little bit) sense of it, they plan to tear everything down and put into place another mumbo-jumbo of Web 3.0 idiocy (rewritten in Rust, no less!)
Just like the xorg/wayland bunch of idiots.
And to add insult to injury, they will make everything closed-garden: no more addons not reviewed by mozilla.inc, even if they're signed and you explicitly trust the developer's certificate!
Basically, OpenSSH was accepting a list of 'keyboard interactive devices' where the same device apeared thousands of times, completely bypassing the MaxAuthTries setting from sshd_config (default 6).
This is well explained in kingcope's original report.
It's very much a bug, and the code in auth2-call.c looks silly enough (just like the fix, btw) that there's a high probability of other such gross bugs in there.
And as OpenBSD developer Marc Espie says in his message,
Not surprisingly, as the patch clearly shows, the problem
is right smack in the middle of USE_PAM code.
That doesn't seem to be the case.
In fact, my will guess is that the default pam_faildelay is what stays in the way of this bug's being exploitable on Linux.
Almost half of the messages in my spam folder are not spam. Basically, any message not originating in their big five/four "cloud" complex is automatically treated as spam, even with freshly allocated and clearly marked as non-dynamic/non-residential IP space.
Moreover, any time I access gmail via ipv6 (I have dual-stack) my messages are marked as spam and I receive terrible warnings about someone else trying to break into my e-mail, and that despite using the same system and browser and the IPv6 whois records pointing to the very same ISP and town as the IPv4 ones. (The funny thing is that they don't tell me that, but that someone is trying to log into my email using "Linux" (as if that wasn't the case everytime).
It seems that despite their pretensions of achieving consciousness and singularity with their AI and stuff, their day-to-day operations are based on 'trusty' cargo-cult more typical of some neighbourhood network run by highschool dropouts.
If the IPv6-designers were
smart enough to just extend the IPv4-address space we would all be
running IPv6 already, because it would require no reconfiguration
of routers
You're an ignorant moron.
Changing ANY field in the IP packet format would require a firmware/software update/recompilation of all network stacks running out there, down to the user programs that just want to open a socket to connect to some server.
Or do you think the addrlen argument passed to connect(3) will just grow by magic in all programs, just because they know it's not the ugly IPv6, but the old, trusty IPv4, just extended with an extra byte?
3. Some compilers don't even try to optimize a
function containing
a goto.
I call bullshit on this.
As to your other points, don't forget that C
doesn't have labeled loops, like java or perl.
So no, "goto" is NOT easy to avoid, if you have
to break out of an inner loop. The alternative
(set a variable then test it on each iteration of
each outer loop) is ugly, messy, inefficient and
is obfuscating the program logic.
Most people that pretend to avoid gotos are
cheating by "refactoring" the resource freeing
blocks into separate functions and then using
multiple return paths, which is just as
anti-Dijkstra as going full gotos everywhere.
There are a lot of routers with an USB that are supported by OpenWRT, TL-MR3420 is not that interesting. I've got my TL-WDR3600 (gigabit, 2 usb ports, 5GHz support) for less than $40. Unfortunately no hardware NAT support on OpenWRT, so I'm limited to ~300Mbs on wan.
If you have a USB-port, you can stick whatever device supported by linux in-there, not just "GSM" modems. The limitations are mostly because of the crappy stock firmware. And many recent HSPA and LTE modems are themselves linux-based routers, and appear like a CDC ethernet interface, so they just work, auto-magically.
As to your scripting in ash, it's the worst of two worlds: its lack of features will criple your scripts, without making them compatible with either the posix or the traditional bourne shell. Solaris'/bin/sh should be a much better target if you want a vanilla shell.
And please stop repeating silly gnu-dissing that makes you feel part of a higher circle: the actual enhancement that 'caused' the shellshock vulnerability (functions as part of environment) was actually copied from plan9's rc, ie the result of the same kind of brainless plan9 snobbery like yours.
ex/vi had ':x' (and ':x!') since its very beginning, which has the advantage of not 'touching' the file gratuitously when no changes were made.
There's also the 'ZZ' command while in visual mode.
Are you also using 'cat | grep'? This parrotting of 'geek creed' signs is really getting on my nerves -- better don't show up with your 'wq:' tee-shirt in my neighborhood;-)
Re:Perl 6ers just can't get shit done.
on
Perl Is Undead
·
· Score: 1
except it's not true that all working interpreters are direct c interpreters.
plan 9's rc implements a virtual machine (which it even bootstraps) and
interprets the virtual machine.
Native code, for example, refers to code in its binary (processor-specific) form. No processor that I'm aware of knows how to run C code natively - it has to first be taken from its portable format and translated into native (assembly and then machine) code. It's not a matter of when or how that translation happens; processors simply don't speak C.
You still don't get it.
Running your Python code is not just a matter of 'translating',
'interpreting', whatever they say in tutorials. The problem is that your program needs/at runtime/ some bloated, slow VM
written in C and it will still need it even if you compile your
program into native code. It simply cannot work without it.
By comparison, if I compile C program for the attiny13a, I get
some dozen or hundred bytes to put into its memory to run through them, and that's it.
And the situation wouldn't change no matter how many compiler passes I do, or what "abstraction level" I use, or whatever. It's still very much an assembler, even if I was
producing machine code from flowcharts, koans or gestures.
Claiming that hardware can run C natively is quite a reach. Your definition of what it means to run a language natively is so broad that it encompasses a large number of programming languages (if not all of them).
It's not about the number of passes of the compiler or if a
language is supposed to be portable or not, but about
the "virtual machine" abstraction a language is assuming,
and how far is that from what typical hardware has to offer.
To run any Lisp or Python program, no matter what interpreter/compiler you use, you need to implement garbage collection, reflection, run-time code evaluation, etc.
Those features are neither light-weight, trivial nor scope-limited, unlike software routines implementing integer multiplication/division (on alpha) or a floating point emulator (on most arms) -- that are needed for a full C implementation.
And if you strip your language of those complex features,
you also lose the 10x productivity you like to claim, and
you simply get a C without pointers.
Not only was Python/originally/ written in C, it/still/ is written in C.
And most hardware is able to run C natively -- C is just a glorified assembler. And ISAs which didn't map nicely to C, like pdp10, are long gone.
Anybody would love a system programming language other than C, less anchored in single-threaded '70 pdp11 concepts and idiosincrasies; but as long as there isn't any, stop pitching your slow bloated language-of-the-day, and pretending that with enough kool-aid and meditation, you can replace C with Java or Python.
Also, android has a linux kernel, which means iptables-based firewalling works
Not necessarily.
On my phone the kernel was built without iptables support.
I had to beg for the modified kernel sources, wait 3 months to get them, and then waste a lot of time to learn about the
stupid idiosyncrasies of 'android is not gnu', just to get
that standard linux feature working.
Great Leaders of the North Korean type come about either because they're sons of another great leader, or because they're choosen by some superpower (Russia) to run puppet-states in their "liberated" territories.
and found that completely unacceptable, I could always choose not to work on such an important project critical to the security of so many.
That the old tired meme used to keep honest competent people out of critical jobs; but unlike generals and politicians, programmers able to work on OpenSSL don't grow up in trees, so you
will have to make do with (almost) the same people and
stuff your "incentives" and "reactions" up your ass.
I do have to wonder if the task was made easier given the purpose
of the server. After all, I'd think it wouldn't get traffic at all
except for those people responding to the challenge.
On the contrary, it may have made things harder.
Reading the private key relies on forcing malloc() to reuse some
small block from the free block list with a lower address than
the block containing the key, insteading of simply carving a new
block out of free memory (with an address higher than the key).
That may be easier to do on a busy server, because you don't have to
send millions of queries just to fragment its memory; you may just
assume that malloc is already reusing freed blocks, and exploit
the algorithm it uses to do that (eg by manipulating the length of
payload to let it allocate some unusual size block for which some
gap just before the key is the perfect fit).
I have met a lot of them, and while they are extremely friendly people, they are also
staunchly conservative when it comes to things like cochlear
implants and what they see as the erosion of Deaf culture.
Does a cochlear implant let one hear as "normal" people do, or at least as much as an 80-old with a hearing aid?
If the answer is "not quite", then they have all the reasons to be conservative.
This bug would have been utterly trivial to detect
when introduced had the OpenSSL developers bothered
testing with a normal malloc (not even a security
This is simply not true, stop spinning it.
Even if OpenSSL is using system's malloc, with all its mitigation features, the bug still works. The attacker just has to be more careful, lest he should read freed() and unmapped memory, and so cause a crash and (supposedly) leave some kind of meaningful trail.
They just included it as delivered by the OpenSSL people (BTW, OpenSSL is a different project, no relation to OpenBSD).
A simple code changes review would have caught such an obvious bug (trusting without checking a buffer length parameter received over the network).
As to their memory randomization thing and how OpenSSL worked around that by wrapping malloc(), that's a red herring; if you're able to read the whole process memory by 64kb, there's no problem to follow all pointers in the manner of a garbage collector, or simply mine it following known patterns.
The Soviets most certainly did have state mandated atheism. You
could get sent to the gulags for admitting to or demonstrating your
religious beliefs.
When was that?
AFAIK, the Orthodox Church was very much scaled back, but its priest,
seminaries, etc were still payed for by the State, and just as in tsarist
times, the Church was an active & enthusiastic organ of the totalitarian
state (the clergy ranks were even assimilated to ranks in the secret police).
Slashdot Mirror
Not for the parallel port. Those usb-parallel adapters are actually emulating a USB printer -- they're absolutely worthless if you want to use them to bitbang microcontrollers and other such things.
In fact, they're absolutely worthless overall -- when did you last see a printer that doesn't support USB?
O God.
As if the xml/xul/xpcom repetitive cargo cult nighmare wasn't bad enough.
Just as the code started to mature a little bit, and despite its ugliness and brittleness, people started to make (a little bit) sense of it, they plan to tear everything down and put into place another mumbo-jumbo of Web 3.0 idiocy (rewritten in Rust, no less!)
Just like the xorg/wayland bunch of idiots.
And to add insult to injury, they will make everything closed-garden: no more addons not reviewed by mozilla.inc, even if they're signed and you explicitly trust the developer's certificate!
Then the article (which I wouldn't bother to read) is misleading.
The bug is inside openssh proper. This is how they fixed it:
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/auth2-chall.c.diff?r1=1.42&r2=1.43&f=h
Basically, OpenSSH was accepting a list of 'keyboard interactive devices' where the same device apeared thousands of times, completely bypassing the MaxAuthTries setting from sshd_config (default 6).
This is well explained in kingcope's original report.
https://kingcope.wordpress.com/2015/07/16/openssh-keyboard-interactive-authentication-brute-force-vulnerability-maxauthtries-bypass/
It's very much a bug, and the code in auth2-call.c looks silly enough (just like the fix, btw) that there's a high probability of other such gross bugs in there.
That doesn't seem to be the case.
In fact, my will guess is that the default pam_faildelay is what stays in the way of this bug's being exploitable on Linux.
Because my mother-in-law was also fuming against it just a day or two ago.
Moreover, any time I access gmail via ipv6 (I have dual-stack) my messages are marked as spam and I receive terrible warnings about someone else trying to break into my e-mail, and that despite using the same system and browser and the IPv6 whois records pointing to the very same ISP and town as the IPv4 ones. (The funny thing is that they don't tell me that, but that someone is trying to log into my email using "Linux" (as if that wasn't the case everytime).
It seems that despite their pretensions of achieving consciousness and singularity with their AI and stuff, their day-to-day operations are based on 'trusty' cargo-cult more typical of some neighbourhood network run by highschool dropouts.
You're an ignorant moron.
Changing ANY field in the IP packet format would require a firmware/software update/recompilation of all network stacks running out there, down to the user programs that just want to open a socket to connect to some server.
Or do you think the addrlen argument passed to connect(3) will just grow by magic in all programs, just because they know it's not the ugly IPv6, but the old, trusty IPv4, just extended with an extra byte?
I call bullshit on this.
As to your other points, don't forget that C doesn't have labeled loops, like java or perl.
So no, "goto" is NOT easy to avoid, if you have to break out of an inner loop. The alternative (set a variable then test it on each iteration of each outer loop) is ugly, messy, inefficient and is obfuscating the program logic.
Most people that pretend to avoid gotos are cheating by "refactoring" the resource freeing blocks into separate functions and then using multiple return paths, which is just as anti-Dijkstra as going full gotos everywhere.
link?
If you have a USB-port, you can stick whatever device supported by linux in-there, not just "GSM" modems. The limitations are mostly because of the crappy stock firmware. And many recent HSPA and LTE modems are themselves linux-based routers, and appear like a CDC ethernet interface, so they just work, auto-magically.
No, it's not.
It's much smaller and faster than bash.
As to your scripting in ash, it's the worst of two worlds: its lack of features will criple your scripts, without making them compatible with either the posix or the traditional bourne shell. Solaris' /bin/sh should be a much better target if you want a vanilla shell.
And please stop repeating silly gnu-dissing that makes you feel part of a higher circle: the actual enhancement that 'caused' the shellshock vulnerability (functions as part of environment) was actually copied from plan9's rc, ie the result of the same kind of brainless plan9 snobbery like yours.
Why?
ex/vi had ':x' (and ':x!') since its very beginning, which has the advantage of not 'touching' the file gratuitously when no changes were made.
There's also the 'ZZ' command while in visual mode.
Are you also using 'cat | grep'? This parrotting of 'geek creed' signs is really getting on my nerves -- better don't show up with your 'wq:' tee-shirt in my neighborhood ;-)
How come? When was that true?
Looking through the source code of rc (http://plan9.bell-labs.com/sources/plan9/sys/src/cmd/rc/) there is absolutely nothing of the sort.
It's a simple interpreter that creates some intermediate bytecode out of the syntax tree, and then execute it in a stack machine.
Very much like mawk or such.
You probably have vague recollections about limbo/inferno, go or other similar failures they've churned out since then.
You still don't get it.
Running your Python code is not just a matter of 'translating', 'interpreting', whatever they say in tutorials. The problem is that your program needs /at runtime/ some bloated, slow VM
written in C and it will still need it even if you compile your
program into native code. It simply cannot work without it.
By comparison, if I compile C program for the attiny13a, I get some dozen or hundred bytes to put into its memory to run through them, and that's it.
And the situation wouldn't change no matter how many compiler passes I do, or what "abstraction level" I use, or whatever. It's still very much an assembler, even if I was producing machine code from flowcharts, koans or gestures.
It's not about the number of passes of the compiler or if a language is supposed to be portable or not, but about the "virtual machine" abstraction a language is assuming, and how far is that from what typical hardware has to offer.
To run any Lisp or Python program, no matter what interpreter/compiler you use, you need to implement garbage collection, reflection, run-time code evaluation, etc.
Those features are neither light-weight, trivial nor scope-limited, unlike software routines implementing integer multiplication/division (on alpha) or a floating point emulator (on most arms) -- that are needed for a full C implementation.
And if you strip your language of those complex features, you also lose the 10x productivity you like to claim, and you simply get a C without pointers.
And most hardware is able to run C natively -- C is just a glorified assembler. And ISAs which didn't map nicely to C, like pdp10, are long gone.
Anybody would love a system programming language other than C, less anchored in single-threaded '70 pdp11 concepts and idiosincrasies; but as long as there isn't any, stop pitching your slow bloated language-of-the-day, and pretending that with enough kool-aid and meditation, you can replace C with Java or Python.
Not necessarily.
On my phone the kernel was built without iptables support.
I had to beg for the modified kernel sources, wait 3 months to get them, and then waste a lot of time to learn about the stupid idiosyncrasies of 'android is not gnu', just to get that standard linux feature working.
Great Leaders of the North Korean type come about either because they're sons of another great leader, or because they're choosen by some superpower (Russia) to run puppet-states in their "liberated" territories.
That's the problem: you're not.
That the old tired meme used to keep honest competent people out of critical jobs; but unlike generals and politicians, programmers able to work on OpenSSL don't grow up in trees, so you will have to make do with (almost) the same people and stuff your "incentives" and "reactions" up your ass.
On the contrary, it may have made things harder.
Reading the private key relies on forcing malloc() to reuse some small block from the free block list with a lower address than the block containing the key, insteading of simply carving a new block out of free memory (with an address higher than the key).
That may be easier to do on a busy server, because you don't have to send millions of queries just to fragment its memory; you may just assume that malloc is already reusing freed blocks, and exploit the algorithm it uses to do that (eg by manipulating the length of payload to let it allocate some unusual size block for which some gap just before the key is the perfect fit).
Does a cochlear implant let one hear as "normal" people do, or at least as much as an 80-old with a hearing aid?
If the answer is "not quite", then they have all the reasons to be conservative.
nb: he's not talking about the heartbleed bug, but about another bug he found in OpenSSL's custom allocator -- a use after free.
This is simply not true, stop spinning it.
Even if OpenSSL is using system's malloc, with all its mitigation features, the bug still works. The attacker just has to be more careful, lest he should read freed() and unmapped memory, and so cause a crash and (supposedly) leave some kind of meaningful trail.
They just included it as delivered by the OpenSSL people (BTW, OpenSSL is a different project, no relation to OpenBSD).
A simple code changes review would have caught such an obvious bug (trusting without checking a buffer length parameter received over the network).
As to their memory randomization thing and how OpenSSL worked around that by wrapping malloc(), that's a red herring; if you're able to read the whole process memory by 64kb, there's no problem to follow all pointers in the manner of a garbage collector, or simply mine it following known patterns.
Was it automatically enabled?
When was that?
AFAIK, the Orthodox Church was very much scaled back, but its priest, seminaries, etc were still payed for by the State, and just as in tsarist times, the Church was an active & enthusiastic organ of the totalitarian state (the clergy ranks were even assimilated to ranks in the secret police).