1,013 karma · joined September 5, 2012
Streaming parsers give you a stream of events like "open tag 'message'", "attribute 'from'", "open tag 'body'", "close tag 'body'" and you need to gather those and translate them back into the top-level elements of the stream. This is pretty tedious, and if you do it wrong you may end up leaking memory (if you keep the entire tree around in memory) or even introduce vulnerabilities (similar to https://bugs.chromium.org/p/project-zero/issues/detail?id=22... ).
Also, I don’t expect it to be 100% correct everywhere, sometimes the GPS data is just not good enough or I might have traveled in a way that the map wouldn’t allow, but there were some instances I found where I thought it should’ve been able to find a match and it didn’t.
Some examples: the GPS error is often more than the distance between a road and a cycling path next to the road, so it often confuses them.
The default cycling profile of OSRM actually takes into account the possibility of dismounting and walking with the bike. This is very useful when that is what you did, but it also creates a lot of extra possibilities. For example, a one way cycling path can then be used in the opposite direction by walking.
There’s also a limit to how many points it can process at once (and it becomes quite slow if you increase that). Should I slice up the trip in multiple segments and then somehow connect them, or is it better to drop some of the points? Still haven’t found out what the best option is.
It also helped me spot some subtle errors or missing data on OSM, but that's easy enough to fix.
Anything not on those locations is not protected, so there's no Data Vault for Chrome's cookie file, for example.
It's not receiving an ICMP packet that causes the crash, it's when sending an ICMP error response packet. ICMP error packets can be generated in response to any type of IP packet, for example "host unreachable" when using UDP. These packets copy the original header of the packet which generated the error, which is where the out-of-bounds copy is.
I understand why the author doesn't want to give full details, but in this case it leads to a lot of misunderstandings on how it works.
IMAP uses SASL, which can do client-side stretching by using SCRAM-SHA-1. I don't know how common they are, but there must be some servers and clients that support it.
Downside is that upgrading the mechanism becomes hard, and it's difficult to integrate it with an existing user database with hashed passwords.
Sadly, there were only a handful available after the event (for about €30). I'm hoping someone continues with the design, because I can think of quite a few applications, but I'm worried about breaking it.
You don't need to use IDNA for this, though. There are standards specifically for dealing with Unicode passwords, such as SASLprep (RFC 4013) and PRECIS (RFC 7564).
> Placing shells in IDAT chunks has some big advantages and should bypass most data validation techniques where applications resize or re-encode uploaded images. You can even upload the above payloads as GIFs or JPEGs etc. as long as the final image is saved as a PNG.
An attacker will likely be able to figure out the exact re-encoding you apply, so unless you add some form of randomness, the attacker can work backwards to get the payload they want included.
What is new (and what appears to make Mozilla's implementation incompatible) is that they are adding a layer of UUIDs to ensure each service gets a separate origin. This ensures that, if you switch between LANs, an open tab for one device can't interact with a device on the other LAN with the same name or IP address. Makes a lot of sense for the security of IoT devices.