coolj

Re:DHCPwn: A DHCP exhaustion tool on Sunday January 03, 2016 @09:47PM (#10833762)

Since this is just sending out DISCOVERs and never REQUESTs on any OFFERs that come back, servers can technically reuse IPS from outstanding offers:

https://tools.ietf.org/html/rfc2131#page-31

      Because the servers have not committed any network address assignments on
      the basis of a DHCPOFFER, servers are free to reuse offered
      network addresses in response to subsequent requests.  As an
      implementation detail, servers SHOULD NOT reuse offered addresses
      and may use an implementation-specific timeout mechanism to decide
      when to reuse an offered address.

I'm curious if common DHCP servers like dnsmasq actually do reuse IPs from pending OFFERs, and what timeout they have, if any, before reuse. I poked around dnsmasq config but I did see any specific tuning for that.

Re:Cool-retro-term: A terminal emulator which mimics the old cathode d... on Thursday October 02, 2014 @09:55AM (#8400719)

Way back in the 90's my CRT monitor went out. Money was tight so I had to wait a couple of weeks before I could replace it. I went to a local computer repair shop (as in, actual repair, like replacing blown capacitors on mainboards and such) to see what I could get for cheap, as a stopgap. The guy had an old monochrome CRT he had repaired--the kind with green pixels--probably 6-7 years old at the time. He sold it to me for like 8 bucks. I figured I could at least use bitchx and links on it until I could get a new monitor. After a few hours in front of it, I started feeling really itchy, and the screen had enough static charge to raise the hairs on my forearm if I moved near it. Pretty sure it was shooting cancer directly into my face. Good times!

Re:Mitch Hedberg and GIS on Tuesday August 19, 2014 @05:45AM (#8196576)

You put together a really awesome project! Kudos on that and for sharing it first and foremost!! I speak regex pretty fluently, and I may very well have reached for sed/perl -ne there as well, depending on mood. I guess it just struck me as odd to use a parser for XML but not JSON. Anyhow, off on a tangent, I recently learned about a program called xgrep that lets you pull elements out of XML using xpath or pcre (althought pcre support was kind of spotty for me)--it's neat for one-offs like this and pipeline building while playing with rest apis and such!

Re:NSA's BIOS Backdoor a.k.a. God Mode Malware on Monday August 18, 2014 @01:07AM (#8191496)

I get the impression that most violent terrorist groups are rather low-tech and are not using _any_ server hardware. If you're aware of terrorists routinely operating DCs or co-locating servers, feel free to correct my understanding.

Re:Mitch Hedberg and GIS on Monday August 18, 2014 @12:49AM (#8191470)

The regexp must have taken some time to write and debug:

s/^."n":"(.+)","i":"(.+)","p":\[([\d\.\-]+),([\d\.\-]+)],"s":"(\w+)","c":"(.+)".$/\1,\2,\3,\4,\5/;

Re:Pyrasite: Tools for injecting code into running Python processes on Monday August 11, 2014 @05:39AM (#8162616)

GDB uses a system call(s) to attach to the running process[1], and python exposes an API that lets you evaluate code in the current VM context[2]. Specifically, https://github.com/lmacken/pyrasite/blob/develop/pyrasite/in...

[1] http://aosabook.org/en/gdb.html [2] https://docs.python.org/2/c-api/veryhigh.html

Re:PostgreSQL Performance on Docker on Thursday July 10, 2014 @03:37PM (#8016739)

> Based on my data, they're not 1:1 native performance. I suggest you consider the data before dismissing it.

I think you're conflating his separate points:

"What you -are- benchmarking is namespaces, cgroups, CoW filesystems and your underlying hardware."

"Also worth nothing that compute benchmarks will be absolutely worthless as they -will- be 1:1 native performance"

Re:Tor Project Sued on Wednesday July 09, 2014 @04:58PM (#8012202)

INAL (but I play on one daytime TV): Their whole claim aginst TOR amounts to:

pp. 2-3

"According to its website, TOR "was originally designed, implemented, and deployed as a third-generation onion routing project of the U.S. Naval Research Laboratory. It was originally developed with the U.S. Navy in mind, for the primary purpose of protecting government communications." The TOR website further states that their products and services are used by individuals "to keep websites from tracking them and their family members, or to connect to news sites, instant messaging services, or the like when these are blocked by their local Internet providers." TOR also provides services that permit users, such as Pinkmeth, to "publish web sites and other services without needing to reveal the location of the site." [...] It is clear from the TOR website that TOR is knowingly assisting websites such as Pinhneth in committing torts against Texas resident..."

p. 5

"However, unscrupulous Internet service companies such as TOR offer "private" or "anonymous" domain name hosting services that allow criminals such as Pinkmeth and its users to escape accountability for their actions. TOR even advertises that with their service "nobody would be able to determine who was offering the site, and nobody who offered the site would know who was posting to it." [...] many unscrupulous companies offer services that allow illegal websites such as Pinkmeth to remain anonymous and difficult for authorities to shut down. Indeed Pinkmeth's Twitter feed advertises its website as being a website "where your state laws don't apply.""

pp. 8-9

"The specific object to be accomplished by the conspiracy was the publication pornographic images of Plaintiff (and other women) on the Pinkmeth website in such a mannner so as to prevent its operators and users from being held civilly and criminally accountable for this unlawful behavior."

This seems to be conflating a few things. The fact that "revenge porn" sites exist outside of anonymous content distribution networks like TOR shows that anonymity wasn't a required component in the tort allegedely commited by Pinkmeth. There are many cases involving sites like that being taken down from public hosting providers. The fact that TOR could allegedly allow defendant to escape prosecution does not equate to a real conspiracy to assist defendant in escaping prosecution. A person hosting a costume party isn't automatically responsible for a murderer taking advantage of the anonymity to commit a crime, without some evidence of collusion.

Re:Show HN: Fast and Extensible Parser for Markdown in PHP on Thursday May 22, 2014 @10:02AM (#7783891)

Can you parse HTML with regex?

http://stackoverflow.com/a/1732454

Re:CloudFlare's Heartbleed challenge cracked on Saturday April 12, 2014 @05:05AM (#7577363)

Brute force is infeasible if you get random heap data along with key fragments. Based on the way the exploit works[0], my amateur guess would be they sent small payloads and actually did get SSLv3 records, because they found the right heap allocation strategy for a specific build on a specific platform.

[0] http://blog.existentialize.com/diagnosis-of-the-openssl-hear...

Re:Spinal cord work 'is a breakthrough' on Tuesday April 08, 2014 @12:05PM (#7554234)

Probably less of a downside than not being able to move your lower body at all, but yeah.

Re:Torn and weary (on Brendan Eich and Mozilla) on Sunday April 06, 2014 @01:52AM (#7539953)

What if it was a donation to Americans United or Planned Parenthood? There are people who earnestly believe that AU hates religions and-or religious people, or that PP hates traditional family structure. What if he donated to a group that was against the Affordable Heathcare Act? What if he donated to a group that was for it? There are many reasons why people may support different causes or groups, and a contribution in and of itself doesn't do anything to show that it is motivated by hate or fear. You need to look at the person's other actions in order to better determine that.

Re:Torn and weary (on Brendan Eich and Mozilla) on Saturday April 05, 2014 @10:14AM (#7537121)

> an opinion people shouldn't be held to account for...

I believe people should be held publicly accountable for their actions, not their thoughts/opinions, no matter how strongly I may disagree with their ideas. I wouldn't be too worried about a CEO of Mozilla who had at some point contributed $1000 to a group trying to stop interracial- (or gay-, or plural-, or cats-and-dogs-) marriage by itself, if it were the person's own money. There are benign reasons a person may support such views, however misguided they may be, without being motivated by hate. So nothing in that contribution alone to makes me suspect the person would behave unfairly in the workplace towards the group of people supporting such marriage or trying to be married. To bring it back from the thought experiment to the current situation, I'm pretty sure a lot of people worked with Brendan at Mozilla, and I haven't heard of anyone coming forward with complaints of homophobia against him after working with/for him... so yeah.

Re:DigitalOcean not destroying droplets securely, data is completely r... on Monday March 31, 2014 @01:51AM (#7499870)

https://defuse.ca/audits/encfs.htm https://defuse.ca/audits/ecryptfs.htm

Probably better to use ecryptfs or dm-crypt.

Re:Google's robots.txt on Sunday February 23, 2014 @04:31AM (#7285393)

curl -s https://raw.github.com/bluedragonz/bad-bot-blocker/master/.h... | awk -F\" '/SetEnvIfNoCase/ {pattern = pattern $2 "|"} END {print "if ($http_user_agent ~ (" substr(pattern, 0, length(pattern)-1) ")) { return 403; }"}'

Not tested. :)

Re:Silicon Valley billionaires believe in the free market, as long as ... on Tuesday February 04, 2014 @06:33AM (#7176778)

Should you judged by the views and actions of others who self-identify as "hackers"? If the label includes people with a wide range of fundamentally incompatible views, it's not very useful to use as a yard stick. It looks a lot like guilt by association.

Re:DigitalOcean leaks customer data between VMs on Monday December 30, 2013 @03:52AM (#6983741)

Agreed. I wasn't defending DO's professionalism there, just saying that from my experience creating base images for a (different) cloud provider, it looks like an artifact of image creation rather than a real cause for alarm (I would certainly be alarmed if random people were logging in to my instance and running random scripts from the web!).

Re:DigitalOcean leaks customer data between VMs on Monday December 30, 2013 @03:37AM (#6983710)

To be honest, this looks like an artifact of the base image creation process.

"This file is used to clean up traces from DigitalOcean images before being published."

I don't think someone actually logged in and ran those commands on your instance. I could be wrong, but I'd bet this is just from sloppy creation of the base image leaving weird stuff in history after the image was published.

Re:DigitalOcean leaks customer data between VMs on Monday December 30, 2013 @03:20AM (#6983667)

> Or, that our policy on not doing a secure delete by default isn't something you agree with?

This one. Choosing insecure defaults for a virtualization API is a Bad Idea. As a rule of thumb (to put it bluntly), people are dumb. If you give them a loaded gun, they will shoot themselves with it. And they will blame you for it. At least put the safety on and make them take a conscious step before blowing their face off. Don't mean to tell you your business, but seriously, insecure defaults are a Bad Idea for a virt API.

Re:DigitalOcean leaks customer data between VMs on Monday December 30, 2013 @02:29AM (#6983538)

Looking at their pricing page, it looks like an instance with 512MB RAM comes with a 20GB disk. Depending on host load, IO and process niceness etc, I can see a `dd if=/dev/zero of=...` taking ~10 minutes easily.

Re:DigitalOcean leaks customer data between VMs on Monday December 30, 2013 @02:07AM (#6983478)

I think he's showing that the data is not "destroyed" in the sense it still exists. Destroy in a virt context doesn't necessarily mean "destroy all the resources associated with a VM"--I don't know about DO's product offering, but at the hypervisor level, at least with Xen and libvirt, you often want to "destroy" the instance (forcibly terminate/undefine from the hypervisor) and leave the resources (storage pools/devices, IP pools/addresses, network flows/filters etc). I think focusing on the word "destroy" is a bit of a canard; the real problem is insecure defaults wrt block device scrubbing when you issue an API "destroy" (which wouldn't be any better if it was called "delete" or "undefine").

Re:DigitalOcean leaks customer data between VMs on Monday December 30, 2013 @01:48AM (#6983421)

DO is essentially saying they're using insecure defaults by design, which is a Really Bad Idea, even if it prima facie saves time/money. It's relatively easy for them to post a point in a FAQ about why you're billed for x minutes after an instance is destroyed, and include the request params/headers to avoid it. On the other hand, it's effectively impossible to unleak an inadvertently leaked apple developer signing key because an unwitting customer didn't rtfm.

Re:DigitalOcean leaks customer data between VMs on Monday December 30, 2013 @01:05AM (#6983295)

If you make an API call that asks for your data NOT to be scrubbed, then it's not a leak that your data isn't scrubbed--you asked for it. If you haven't read the docs, you might not be aware that you're asking for it. That's a Bad Thing. No question. It should be enabled by default, to prevent unknowing users from leaking their own data. If you ask for a scrub and you can still find data on the scrubbed block device, then you have a leak from DO.

Re:DigitalOcean leaks customer data between VMs on Monday December 30, 2013 @12:47AM (#6983235)

I don't really see how this is leaking data. I can use the dropbox API to make a bunch of files with private data shared with the world. But dropbox isn't "leaking" my data, I'm using the API in such a way that makes my data accessible. Not an exact analogy, and I would agree that the option should be on by default so people who know what they're doing can opt-out and everyone else gets a safer default, but this isn't a "data leak."

Re:DigitalOcean leaks customer data between VMs on Monday December 30, 2013 @12:38AM (#6983215)

Also, even if they zero the primary block device, what about swap if it's provided as a separate block device?

Re:Rebuilding the line-mode browser (in node.js) on Thursday September 26, 2013 @08:06AM (#6450135)

Check out the Mouseless Browsing extension if you're using firefox:

https://addons.mozilla.org/en-us/firefox/addon/mouseless-bro...

It's overkill to have it show the IDs all the time, so you can disable that and set a shortcut to toggle them on and off so you only get them when you want them.

Re:What I learned from others' shell scripts on Wednesday August 14, 2013 @04:57AM (#6210509)

http://www.tldp.org/LDP/abs/html/

TLDP's Advanced Bash-Scripting Guide is a great resource for learning bash.

For example, this section talks about the meaning of "$*":

http://www.tldp.org/LDP/abs/html/internalvariables.html#ARGL...

Re:mpv - a free and open-source general-purpose video player on Sunday August 11, 2013 @09:00AM (#6194861)

It's nice to see a renewed interest in developing mplayer. Do you know if there are plans to get it packaged by the major distros?

Re:Scala vs. Go TCP Benchmark on Wednesday August 07, 2013 @06:37AM (#6171880)

> Interesting, but now I'm even more confused. How can we possibly explain that a (go client -> go server) (which are in separate go processes) performs far worse than (go -> scala server), given that the go server seems to be better when using the scala client?

I've been curious about that as well. The major slowdown seems to be related to a specific combination of go server and client. I don't have a good explanation. I'd love to hear from someone familiar with go internals.

> go server + go client 22.02125152 > ... > scala server + go client 4.766823392

That's roughly equivalent to my numbers.

Re:Scala vs. Go TCP Benchmark on Tuesday August 06, 2013 @06:38AM (#6165777)

Interestingly, both the go client and the scala client perform the same speed when talking to the scala server (~3.3s total), but the scala client performs much faster when talking to the go server (~1.9s total), whereas the go client performs much worse (~23s total, ~15s with GC disabled).

I thought the difference might partly be in socket buffering on the client, so I printed the size of the send and receive buffers on the socket in the scala client, and set them the same on the socket in the go client. This didn't actually bring the time down. Huh.

My next thought was that scala is somehow being more parallel when it evaluates the futures in Await.result. Running `tcpdump -i lo tcp port 1201` seems to confirm this. The scala client has a lot more parallelism (judging by packet sequence ids). Is that really because go's internal scheduling of goroutines is causing lock contention or lots of context switching?

And...googling a bit, it looks like that is the case: https://docs.google.com/document/d/1TTj4T2JO42uD5ID9e89oa0sL...

> Current goroutine scheduler limits scalability of concurrent programs written in Go, in particular, high-throughput servers and parallel computational programs. Vtocc server maxes out at 70% CPU on 8-core box, while profile shows 14% is spent in runtime.futex(). In general, the scheduler may inhibit users from using idiomatic fine-grained concurrency where performance is critical.